353150 - [trunk]Build process is killed while processing nsJARProtocolHandler.cpp/.h with gcc 4.1 - related to gcc bug 26905

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Frederic Bezies]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060918 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060918 Minefield/3.0a1

Simple to see. I am testing Ubuntu Edgy Eft in a virtual machine, and one of my tests is to get build process of firefox (or any other software of the Mozilla Foundation) to its normal end.

But, when I tried to build the trunk with gcc 4.1.1 (the ubuntu version), build process kills itself, saying :

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 -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2 -pipe -w -fPIC -shared -Wl,-z,defs -Wl,-h,libjar50.so -o libjar50.so  nsZipArchive.o nsWildCard.o nsJARInputStream.o nsJARDirectoryInputStream.o nsJAR.o nsJARFactory.o nsXPTZipLoader.o nsJARProtocolHandler.o nsJARChannel.o nsJARURI.o    -lpthread    -Wl,--version-script -Wl,../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -L../../dist/bin -L../../dist/lib -L../../dist/lib -lmozz -L../../dist/bin -lxpcom -lxpcom_core  -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl  -ldl -lm    
nsJAR.o:(.data.rel.ro._ZTV16nsZipReaderCache[vtable for nsZipReaderCache]+0x54): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**)       »
nsJARProtocolHandler.o:(.data.rel.ro._ZTV20nsJARProtocolHandler[vtable for nsJARProtocolHandler]+0x4c): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**)       »
collect2: ld returned 1 exit status

It looks like it could not find a reference, nsSupportsWeakReference::GetWeakReference(nsIWeakReference** one ?!

Could it be related to bug 210305 in some ways ? Last modification for nsJARProtocolHandler.cpp is very young, so ?!

Reproducible: Always

Steps to Reproduce:
1.Install ubuntu edgy knot 3 and all building tools
2.launch building
3.

Actual Results:  
crash while making libjar50.so :(

Expected Results:  
Going on.

here is the gcc information :

s$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060906 (prerelease) (Ubuntu 4.1.1-13ubuntu2)

And the .mozconfig I am using for this building :

#
# See http://www.mozilla.org/build/ for build instructions.
#

. $topsrcdir/browser/config/mozconfig

# Options for 'configure' (same as command-line options).
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --disable-freetype2
ac_add_options --enable-pango
ac_add_options --enable-canvas
ac_add_options --enable-svg
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-optimize="-O2 -pipe -w"
ac_add_options --enable-strip
ac_add_options --disable-pedantic
ac_add_options --enable-static
ac_add_options --disable-shared

Comment 1

[Frederic Bezies]

Woops, I looked bad when looking at last changes. Maybe a gcc 4.1.1 bug :(

Feel free to close it if you think it is a gcc 4.1.1 bug.

Comment 2

[Benjamin Smedberg]

I've seen several reports of this from Ubuntu users and the general consensus is that it's a compiler or linker bug.

Comment 3

[Frederic Bezies]

So, let's close it the good way -> INVALID.

Comment 4

[Frederic Bezies]

Reopening it. As ubuntu developper (see 
https://launchpad.net/distros/ubuntu/+source/gcc-4.1/+bug/61104)  doesn't seem to care a lot about this behaviour, maybe you can find a workaround for this gcc bug.

I tried building in shared libs mode, and it crashes sooner than in static libs mode :

rm -f libxpconnect.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 -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O3 -pipe -w -fno-strict-aliasing -fPIC -shared -Wl,-z,defs -Wl,-h,libxpconnect.so -o libxpconnect.so nsScriptError.o nsXPConnect.o xpccallcontext.o xpccomponents.o xpccontext.o xpcconvert.o xpcdebug.o xpcexception.o xpcjsid.o xpcjsruntime.o xpclog.o xpcmaps.o xpcmodule.o xpcruntimesvc.o xpcstack.o xpcstring.o xpcthreadcontext.o xpcthrower.o xpcwrappedjs.o xpcvariant.o xpcwrappedjsclass.o xpcwrappednative.o xpcwrappednativeinfo.o xpcwrappednativejsops.o xpcwrappednativeproto.o xpcwrappednativescope.o XPCNativeWrapper.o -lpthread -Wl,--whole-archive ../loader/libjsloader_s.a -Wl,--no-whole-archive -L../../../../dist/bin -lxpcom -lxpcom_core -L../../../../dist/bin -L../../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L../../../../dist/bin -lmozjs -Wl,--version-script -Wl,../../../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -ldl -lm
nsXPConnect.o:(.data.rel.ro._ZTV11nsXPConnect[vtable for nsXPConnect]+0xc4): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcruntimesvc.o:(.data.rel.ro._ZTV22nsJSRuntimeServiceImpl[vtable for nsJSRuntimeServiceImpl]+0x38): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcthreadcontext.o:(.data.rel.ro._ZTV29nsXPCThreadJSContextStackImpl[vtable for nsXPCThreadJSContextStackImpl]+0x48): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcwrappedjs.o: In function `nsXPCWrappedJS::GetWeakReference(nsIWeakReference**)':
xpcwrappedjs.cpp:(.text+0x22a): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
collect2: ld returned 1 exit status
make[5]: *** [libxpconnect.so] Erreur 1
make[5]: quittant le répertoire « /home/fred/logs/mozilla/js/src/xpconnect/src »
make[4]: *** [libs] Erreur 2
make[4]: quittant le répertoire « /home/fred/logs/mozilla/js/src/xpconnect »
make[3]: *** [libs_tier_gecko] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/mozilla »
make[2]: *** [tier_gecko] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/mozilla »
make[1]: *** [default] Erreur 2

If you want, I can add the build log related to older comments.

Comment 5

[Frederic Bezies]

As far as I remember, when I entered make -f client.mk build, there were a message related to a gcc bug, number 20695 or something like this. Could it be related ?

Comment 6

[Frederic Bezies]

I had this in the start of the build log :

"checking For gcc visibility bug with class-level attributes (GCC bug 26905)... c++: -z: linker input file unused because linking not done
c++: defs: linker input file unused because linking not done
test: 1: ==: unexpected operator
no"

Is this related to this bug ?

Comment 7

[Benjamin Smedberg]

the -z defs warnings are not a problem
the == warning may be an issue

Comment 8

[Frederic Bezies]

Well, I'm trying to help. Maybe it could be a way to find a work-around for this bug ?!

Comment 9

[Frederic Bezies]

Followup of this nightmare.

I tried again but this time, using gcc-4.0, instead of 4.1.

So, I add in the .mozconfig file those two lines :

export CPP=g++-4.0
export CC=gcc-4.0

And I got this bug...

checking for tar... tar
tar
checking for valid optimization flags... no
configure: error: These compiler flags are invalid: -O3 -pipe -w -march=pentium4
*** Fix above errors and then restart with               "make -f client.mk build"

After removing the check lines for optimization, configure crashes telling me it couldn't build X11 software just after the test for tar version.

Of course, I had installed all headers for X11 development.

And if I remove both export lines from .mozconfig, configure part go to its normal end.

This is driving me crazy :(

Comment 10

[cls]

(In reply to comment #9)
> export CPP=g++-4.0
> export CC=gcc-4.0

That should be:

CC=gcc-4.0
CPP=cpp-4.0
CXX=g++-4.0

Comment 11

[Frederic Bezies]

Well, still crashing... Even using gcc4 tools. And still crashing in the same point as in comment #0.

"g++-4.0  -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O3 -pipe -w -march=pentium4 -fPIC -shared -Wl,-z,defs -Wl,-h,libjar50.so -o libjar50.so  nsZipArchive.o nsWildCard.o nsJARInputStream.o nsJARDirectoryInputStream.o nsJAR.o nsJARFactory.o nsXPTZipLoader.o nsJARProtocolHandler.o nsJARChannel.o nsJARURI.o    -lpthread    -Wl,--version-script -Wl,../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -L../../dist/bin -L../../dist/lib -L../../dist/lib -lmozz -L../../dist/bin -lxpcom -lxpcom_core  -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl  -ldl -lm    
nsJAR.o:(.gnu.linkonce.d._ZTV16nsZipReaderCache[vtable for nsZipReaderCache]+0x54): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**)       »
nsJARProtocolHandler.o:(.gnu.linkonce.d._ZTV20nsJARProtocolHandler[vtable for nsJARProtocolHandler]+0x4c): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**)       »
collect2: ld a retourné 1 code d'état d'exécution
make[4]: *** [libjar50.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/logs/fox/mozilla/modules/libjar »
make[3]: *** [libs_tier_gecko] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make[2]: *** [tier_gecko] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make: *** [build] Erreur 2"

So there is not a bug in mozilla, but in ubuntu. And as ubuntu maintener for gcc doesn't seem to admit it, I let you free to close this bug if you want.

And I will throw ubuntu edgy and its crappy version of gcc to /dev/null. Sorry to use rude words, but I am kinda fed up ! :(

Thanks for your help.

Comment 12

[Frederic Bezies]

I am wondering if it is not a bug in ld ? And if so, is there any workaround which could be added to bypass this bug ?

ld is the last command before build crash, after all !

Comment 13

[Frederic Bezies]

Maybe looking at changelog for ubuntu firefox package could help working around this ld related bug ?

http://packages.ubuntu.com/edgy/web/firefox
http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.99+2.0b2+dfsg.orig.tar.gz
http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.99+2.0b2+dfsg-1ubuntu2.diff.gz

Comment 14

[Heinrich Witt]

(In reply to comment #13)
> Maybe looking at changelog for ubuntu firefox package could help working around
> this ld related bug ?
> 
> http://packages.ubuntu.com/edgy/web/firefox
> http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.99+2.0b2+dfsg.orig.tar.gz
> http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.99+2.0b2+dfsg-1ubuntu2.diff.gz
> 

That are branch-builds.....
And they are ok.

Comment 15

[Heinrich Witt]

(In reply to comment #13)
> Maybe looking at changelog for ubuntu firefox package could help working around
> this ld related bug ?
> 
> http://packages.ubuntu.com/edgy/web/firefox
> http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.99+2.0b2+dfsg.orig.tar.gz
> http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/firefox_1.99+2.0b2+dfsg-1ubuntu2.diff.gz
> 

That are branch-builds.....
And they are ok.
I can compile them, but no one trunk-build.

Comment 16

[Frederic Bezies]

Argh !

So, I will have to kick edgy eft ass and install Fedora Core 6 instead ?

Ouch :(

Comment 17

[Frederic Bezies]

Maybe it is the answer ?

From diff change for firefox 2 edgy package :

@@ -7783,7 +7689,7 @@
 
 if test "$GNU_CC"; then
   echo $ac_n "checking for visibility(hidden) attribute""... $ac_c" 1>&6
-echo "configure:7787: checking for visibility(hidden) attribute" >&5
+echo "configure:7693: checking for visibility(hidden) attribute" >&5
 if eval "test \"`echo '$''{'ac_cv_visibility_hidden'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else

Could it be applied to trunk source code ?

Comment 18

[Christian Persch (GNOME) (away; not receiving bug mail)]

Attachment: possible fix

This may or may not fix this bug (still building), but there's a problem in the configure test for the gcc visibility bug: test == is a bashism, and in edgy /bin/sh is dash; so the test mistakenly fails to detect the gcc bug.

Comment 19

[Frederic Bezies]

Will try this patch too.

Keeping fingers crossed of course ;)

Comment 20

[Frederic Bezies]

Holy s**t !

This patch doesn't work for me :(

Still having :

"[...]
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 -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2 -pipe -w -fPIC -shared -Wl,-z,defs -Wl,-h,libjar50.so -o libjar50.so  nsZipArchive.o nsWildCard.o nsJARInputStream.o nsJAR.o nsJARFactory.o nsXPTZipLoader.o nsJARProtocolHandler.o nsJARChannel.o nsJARURI.o    -lpthread    -Wl,--version-script -Wl,../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -L../../dist/bin -L../../dist/lib -L../../dist/lib -lmozz -L../../dist/bin -lxpcom -lxpcom_core  -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl  -ldl -lm    
nsJAR.o:(.data.rel.ro._ZTV16nsZipReaderCache[vtable for nsZipReaderCache]+0x54): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**)       »
nsJARProtocolHandler.o:(.data.rel.ro._ZTV20nsJARProtocolHandler[vtable for nsJARProtocolHandler]+0x4c): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**)       »
collect2: ld returned 1 exit status
make[4]: *** [libjar50.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/logs/fox/mozilla/modules/libjar »
make[3]: *** [libs_tier_gecko] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make[2]: *** [tier_gecko] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make: *** [build] Erreur 2"

Comment 21

[Frederic Bezies]

Please don't care about my last comment. Like an idiot I forget to run autoconf in order to update configure.

/me is ashamed for spamming.

Testing again to build with an updated configure file.

Comment 22

[Frederic Bezies]

Well, after refreshing configure file, build process goes to its good end.

I am using a freshly homemade firefox. So, it looks like to be good ?!

Comment 23

[Mats Palmgren (inactive)]

*** Bug 359036 has been marked as a duplicate of this bug. ***

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I checked this patch in to the trunk.

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 243598 [details] [diff] [review]
possible fix

approved for 1.8 branch, a=dveditz for drivers

Comment 26

[Reed Loden [:reed]]

This patch does not apply successfully to the branch, as it is missing some other patch.

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 243598 [details] [diff] [review]
possible fix

Didn't make 1.8.1.1, try next time

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Or, to put it another way, the patches that caused the bug (bug 334866 and bug 319012) were never checked in on the branch, so the bug isn't there.

Comment 29

[Reed Loden [:reed]]

Comment on attachment 243598 [details] [diff] [review]
possible fix

Clearing approval request, as per comment #28.

Comment 30

[Daniel Veditz [:dveditz]]

Marking dependency so that if bug 334866 *does* land on the branch this might get found.