Bug 432138

Summary:	Mozilla 1.8 fails to compile with gcc 4.3
Product:	[Fedora] Fedora	Reporter:	Kai Engert (:kaie) (inactive account) <kengert>
Component:	mozilla	Assignee:	Christopher Aillon <caillon>
Status:	CLOSED NOTABUG	QA Contact:	Ben Levenson <benl>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	caillon, jakub, stransky
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-04 17:02:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kai Engert (:kaie) (inactive account) 2008-02-09 00:57:10 UTC

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.

Comment 1 Kai Engert (:kaie) (inactive account) 2008-02-09 01:11:22 UTC

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

Comment 2 Kai Engert (:kaie) (inactive account) 2008-02-09 01:12:14 UTC

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

Comment 3 Kai Engert (:kaie) (inactive account) 2008-02-09 01:35:03 UTC

http://koji.fedoraproject.org/koji/getfile?taskID=403691&name=build.log

Comment 4 Kai Engert (:kaie) (inactive account) 2008-02-09 02:06:59 UTC

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) (inactive account) 2008-02-14 21:36:49 UTC

It turns out the bug was caused by Mozilla code, see the Mozilla bug.
Closing as UPSTREAM.

Comment 6 David Walluck 2008-03-04 16:35:01 UTC

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) (inactive account) 2008-03-04 17:02:24 UTC

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 16:09:28 UTC

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.

Comment 9 Kai Engert (:kaie) (inactive account) 2008-03-18 21:59:06 UTC

glad to hear, thanks for letting us know