switch all linux mozilla builds to gcc 3.2

RESOLVED FIXED

Status

SeaMonkey
Build Config
RESOLVED FIXED
16 years ago
14 years ago

People

(Reporter: dmose, Assigned: Daniel (Leaf) Nunes)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Depends on: 116444
(Reporter)

Updated

16 years ago
Depends on: 158387
(Reporter)

Updated

16 years ago
Depends on: 158391
.
Assignee: seawood → dmose

Comment 2

16 years ago
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?

Comment 4

16 years ago
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.

Comment 6

16 years ago
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.

Comment 7

16 years ago
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.

Updated

16 years ago
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.

Updated

16 years ago
Blocks: 53486

Comment 9

16 years ago
Beware http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=168134 which reports a
Mozilla ICE w/ gcc 3.2.

Comment 10

16 years ago
Besides the fact that the compiler used in that bug is not gcc-3.2... (hint:
debian calls the executable g++-3.2)

Comment 11

16 years ago
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.

Comment 12

16 years ago
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. =)

Comment 13

16 years ago
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)

Comment 14

15 years ago
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.

Comment 16

15 years ago
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."

Comment 17

15 years ago
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 
(Reporter)

Comment 19

15 years ago
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
(Reporter)

Comment 20

15 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.