mozilla's install hanging on amd64
michaelnottebrock at gmx.net
Tue Apr 12 10:37:17 PDT 2005
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.
> 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
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
More information about the freebsd-ports