Closed Bug 158385 Opened 22 years ago Closed 21 years ago

switch all linux mozilla builds to gcc 3.2

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dmosedale, Assigned: leaf)

References

Details

We want this largely so that we can then turn on -O2, which isn't possible with
our current compilers (egcs 1.1.2).

There are a number of issues which need to be solved before this can happens;
those bugs will be marked as blocking this one.
Depends on: 116444
Depends on: 158387
Depends on: 158391
.
Assignee: seawood → dmose
FYI gcc-3.2 has a (Yet Another) ABI change, making c++ code compiled with it
incompatible on earliere gcc compilers.
It's important to note that I don't think there are any major Linux vendors who
are going to end up shipping gcc 3.1 or gcc 3.0.

Did anyone ship 3.0?
Mandrake 9.0 beta ships with gcc 3.1 and all system compiled with it. So
Mandrake 9 will ship with probably with gcc 3.2 as it will contains c++ abi
fixes and probably Suse & Redhat will follow.
The last Red Hat beta from a few days ago is shipping with a 3.2 pre-release
with the ABI changes and most of the C++ changes.
Mandrake 9.0 beta 2 has already switched to gcc 3.2 pre-release and final Mdk
9.0 will ship with gcc 3.2 final..

All linux distros (and even FreeBSD) have agreed to use gcc 3.2 to ensure C++
ABI is conformed to the V3 multi-vendor standard.
Well some distros like my Slackware Linux wont upgrade to gcc 3.2 unless Linus
says "Gcc 3.2 is kernel compiler now" . So I think its a better idea to provide
gcc 2.95.3 compiled mozillas.
Depends on: 107976
I don't think this legitimately depends on 107976.  Just make sure "gcc" points
to gcc 3.2 and you don't need support for overriding the compiler coreconf uses.
Blocks: O2
Beware http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=168134 which reports a
Mozilla ICE w/ gcc 3.2.
Besides the fact that the compiler used in that bug is not gcc-3.2... (hint:
debian calls the executable g++-3.2)
g++ is a part of gcc. But, yes, it is a snapshot... and apparently newer
snapshots fixed it. So that is no longer a problem.
Debian's default compiler for all its binaries is gcc-3.2. gcc-2.95 is quickly
becoming obsolete. Besides there's the issue of the loose of performance (the
GCC team claims gcc-3.2 produces 10% faster code, can we add another 10% of not
being able to use full optimization?). Sorry for the spam. =)
FreeBSD-CURRENT's default compiler is:
$ gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20021119 (release)

and Mozilla works great (built from scratch)
Debian sid now contains Mozilla 1.2.1 compiled with gcc/g++ 3.2.
FWIW, the brad tinderbox Z value went down 311K (over two steps, for some odd
reason - possibly the compiler was updated half way through) when it was
upgraded to 3.3 (well, the debian 3.3 prerelease)

It also now produces 40000 warnings, but thats using a non-default warning flag
warning about a gcc ABI bug, and theres a bug on that to work arround the issue.

Random loser was js_interpret @+3.8K; random winner was
nsIndexedToHTML::OnStartRequest @-0.9K. js_Interpret looks like loop unrolling
of some sort, or possibly inlining; there are a lot of changes and its hard to
work out what is happening. The nsIndexedToHTML change is coming from lots of
little places, it appears.

It also looks like the compiler is skipping some virtual call overhead; I see:

-       movl    _ZTV24nsASingleFragmentCString@GOT(%ebx), %ecx
-       addl    $8, %ecx
-       movl    %eax, -1064(%ebp)
-       movl    %eax, -88(%ebp)
+       leal    -104(%ebp), %eax
+       movl    _ZTV18nsDependentCString@GOT(%ebx), %esi
+       addl    $8, %esi
+       movl    %eax, -1172(%ebp)

I can't seem to match that chunk to a source code line to see exactly what is
happening, though.
Java plugin 1.4.2 will work correctly with Mozilla, for more information see
this Java bugParade bug:
<http://developer.java.sun.com/developer/bugParade/bugs/4687814.html>

Choice quote from that bug:

"FRI JUN 07 12:48 P.M. 2002
steven_m_katz

No it is a Mozilla issue in that Mozilla's answer to
compatability of the plugin interface has always been,
"Those interfaces arn't final until the product ships and we
can and do change them at will".  They are perfectly within
their right to say this, but it makes support of Mozilla
impossible given the long lead times inherent in the release
of the JRE/plugin.  Maybe that situation will change now
that 1.0 has shipped.  

To further complicate matters, Netscape shipped product
based on these changable interfaces.  Since the two browsers
are not compatable and we don't have the resources to
support each version of Netscape and every version of
pre-release Mozilla, we had to make a choice.  That choice
was to support the released product (ie Netscape).

The most current verison of Mozilla's plugin interface is
definitly a step in the right direction.  It eliminates the
use of static C++ symbols which should make the choice of
compiler a non-issue.

So what Sun is saying when it says they don't support
Mozilla is:  "We expect the two browsers, Netscape and
Mozilla, to provide bug for bug compatable plugin
interfaces.  To the extent that they don't we will choses to
support Netscape."

I urge the user community to push both Netscape and Mozilla
to keep their plugin intefaces in sync."


But the comment quoted in comment #16 was entered on June 7, 2002--over a year
ago. The "evaluation" section of the Java bug has the following annotation,
entered in March 2003: 
   We need to build two version of OJI plugin due to SuSe8.1 release 
   which ships the 3.2 compiled Mozilla.
Didn't Red Hat and Sun recently enter a partnership whereby Red Hat will
distribute Sun's JDK? If so, this problem must be on Sun's radar screen.
Thought I'd point out that sometime recently, this sort of happened (though this
is just one build, and not sure it pertains to all the builds we spin).  I just
downloaded Mozilla build 2003062805 and my about:buildconfig says:


Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-pedantic -Wno-long-long -g -pthread -pipe
c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-pedantic -Wno-long-long -g -fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--disable-tests --enable-extensions=default,irc --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug --enable-optimize --disable-elf-dynstr-gc
--enable-crypto 
The default builds have indeed changed, thanks to leaf's hard work.  This means
we can now switch them to -O2.  Woot!
Assignee: dmose → leaf
Fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.