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 `/builddir/build/BUILD/mozilla/xpcom/obsolete/component' 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.
I filed bugs against mozilla and gcc: https://bugzilla.mozilla.org/show_bug.cgi?id=416463 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35145
Here is the full list of packages that I downgraded, which made it work: boost-1.34.1-7.fc9.i386.rpm boost-devel-1.34.1-7.fc9.i386.rpm cpp-4.1.2-36.i386.rpm gcc-4.1.2-36.i386.rpm gcc-c++-4.1.2-36.i386.rpm gcc-gfortran-4.1.2-36.i386.rpm libgcc-4.1.2-36.i386.rpm libgfortran-4.1.2-36.i386.rpm libgomp-4.1.2-36.i386.rpm libstdc++-4.1.2-36.i386.rpm libstdc++-devel-4.1.2-36.i386.rpm libtool-1.5.24-3.fc8.i386.rpm libtool-ltdl-1.5.24-3.fc8.i386.rpm taglib-1.5-0.7.20080116svn.fc9.i386.rpm
http://koji.fedoraproject.org/koji/getfile?taskID=403691&name=build.log
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.
It turns out the bug was caused by Mozilla code, see the Mozilla bug. Closing as UPSTREAM.
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.
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.
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 2.0.0.12-2 and it builds.
glad to hear, thanks for letting us know