Bug 432138 - Mozilla 1.8 fails to compile with gcc 4.3
Mozilla 1.8 fails to compile with gcc 4.3
Product: Fedora
Classification: Fedora
Component: mozilla (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Christopher Aillon
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-02-08 19:57 EST by Kai Engert (:kaie)
Modified: 2008-03-18 17:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-04 12:02:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kai Engert (:kaie) 2008-02-08 19:57:10 EST
I attempted to build the latest stable Mozilla branch (1.8, equivalent to
firefox 2 and seamonkey 1.1.8) on Rawhide using gcc 4.3.

It fails with the following output:

rm -f libxpcom_compat_c.so
c++  -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wno-long-long -pedantic -g -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -fPIC -shared -Wl,-z,defs
-Wl,-h,libxpcom_compat_c.so -o libxpcom_compat_c.so  nsXPCOMObsolete.o
nsRegistry.o       -L../../../dist/bin -lxpcom -lxpcom_core 
-L../../../dist/bin -L/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl
-L../../../dist/lib -lxpcom_compat  -Wl,--version-script
-Wl,../../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic
-ldl -lm   
nsXPCOMObsolete.o:(.data.rel.ro+0x18): undefined reference to
`nsFileSpecImpl::Create(nsISupports*, nsID const&, void**)'
nsXPCOMObsolete.o:(.data.rel.ro+0x50): undefined reference to
`nsDirectoryIteratorImpl::Create(nsISupports*, nsID const&, void**)'
/usr/bin/ld: libxpcom_compat_c.so: hidden symbol
`nsFileSpecImpl::Create(nsISupports*, nsID const&, void**)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
gmake[2]: *** [libxpcom_compat_c.so] Error 1
gmake[2]: Leaving directory
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory `/builddir/build/BUILD/mozilla/xpcom/obsolete'
make: *** [libs] Error 2

For testing purposes I downgraded to the older gcc 4.1.2 packages (which were in
f9 alpha 1), and that works just fine.
Comment 1 Kai Engert (:kaie) 2008-02-08 20:11:22 EST
I filed bugs against mozilla and gcc:
Comment 2 Kai Engert (:kaie) 2008-02-08 20:12:14 EST
Here is the full list of packages that I downgraded, which made it work:

Comment 4 Kai Engert (:kaie) 2008-02-08 21:06:59 EST
The original failure was in the automatic build environment "koji" on i386.

I was able to reproduce the build failure on a i386 rawhide system that was
running as a VM guest on a i386 host.

For performing some NSS tests I was in need to test gcc 4.3.0 on x86_64, so I
just completed installing the latest rawhide on that machine too. To my surprise
I don't get the failure there. It might have to do with build flags, as on the
x86_64 I was using my personal build scripts, which on the i386 guest I was
using the rpmbuild system.
Comment 5 Kai Engert (:kaie) 2008-02-14 16:36:49 EST
It turns out the bug was caused by Mozilla code, see the Mozilla bug.
Closing as UPSTREAM.
Comment 6 David Walluck 2008-03-04 11:35:01 EST
There's apparently a fix for this upstream:
<https://bugzilla.mozilla.org/show_bug.cgi?id=416463>. Can it be fixed in
rawhide since it can also prevent the compilation of extensions.
Comment 7 Kai Engert (:kaie) 2008-03-04 12:02:24 EST
I was about to post a comment, saying it's wrong to reopen this bug, because
there is no bug in gcc.

But Jakub was quicker than me in changing components and reassigning. And still,
the following comments apply, and I still believe this bug is INVALID:

David, the upstream fix is exactly what I used to build the seamonkey package
for rawhide.

What other Mozilla applications are you concerned about?

The fix is to the Mozilla sources, so every Mozilla application must be patched,
or it must pick up a newer cvs snapshot.

As far as I can tell, Firefox 3 does not need the fix.

When Thunderbird recently got updated in rawhide, the upstream patch got
applied, too.

If there is need for action on some mozilla packages, please name them.

Comment 8 David Walluck 2008-03-17 12:09:28 EDT
What happened was that I was trying to build an extension with a tarball that
didn't have the latest patches. I added the patch from and it builds.
Comment 9 Kai Engert (:kaie) 2008-03-18 17:59:06 EDT
glad to hear, thanks for letting us know

Note You need to log in before you can comment on or make changes to this bug.