mozilla's install hanging on amd64

[Michael Nottebrock]

Mikhail Teterin wrote:

> So, now you accuse me of lying... The only potentially -march-related problem 
> I had before was with mozilla and the flag was -march=p2.

Interesting.

> It would build and 
> install, but would not start.

FWIW, a root-owned ~/.mozilla can cause this behaviour, too... I have been 
bitten by that multiple times, both with mozilla and firefox. Building with 
sudo lets this happen easily :-\.

> I still have the machine... When I reported 
> this error to gnome@ a year or so ago, I was similarly "yelled" at, that 
> -march setting is not supposed to work...

No, just not supported (by us, the porters). "Not supported" means "if it 
breaks and turning off fixes it, then you have the choice of coming up with a 
fix/workaround yourself and submitting it to the porters / upstream developers 
which may or may not use it at their discretion or not use -march for the 
respective port.

It should be obvious to you why almost everybody, be it upstream developer or 
port-maintainer is so hesitant to make a commitment to all possible 
code-generation options and other gimmicks that gcc offers - they *do*, like 
it or not, occasionally trigger bugs, which usually are very hard to reproduce 
and harder to nail down.

>>>make.conf(5) documents it, it should work. Period.
>>
>>make.conf(5) documents CFLAGS. What would you like to infer from that fact?
> 
> 
> In its documentation of CFLAGS, the man-page warns, that levels other than "-O 
> and -O2" are not supported.

But it doesn't warn about all the other optimization switches you could specify.

> There is nothing about any risk of 
> processor-specific flags like -march, and rightly so.

*sigh*. I don't get how can you seriously claim that using a specialised 
code-generation setting, which obviously must receive less developer-side and 
real-world testing than the standard one does not entail a risk.

> CPUTYPE's paragraph rightly encourages setting the variable to the actual CPU 
> flavor. Everything except the mozilla port (and I have 222 ports installed on 
> this machine already) built fine. Few things have self-test capabilities, but 
> those, that do (Perl, lcms) passed their tests.
> 
> 
>>If a compiler optimization produces a bad binary while the same compiler
>>with the switch off does not (or a different version of the compiler with
>>the switch does not), the compiler usually *is* to blame.
> 
> 
> Scott has responded to this already.

Aliasing rules shouldn't be influenced by -march. In fact, I shouldn't have 
said "optimization" there, since -march (should) not trigger 
architecture-specific optimization, just code-generation (i.e. things like the 
used instruction set, instruction scheduling, register allocation). And yet 
that's plenty enough to hide bugs in, sometimes nasty enough to even cause 
internal compiler errors. I myself have filed -march related bugreports 
against gcc in the past.

-- 
    ,_,   | Michael Nottebrock               | lofi at freebsd.org
  (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
    \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org