As HJL requested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276 on 2004-07-08, here is a new bug report and a testcase which now unfolds the g++-bug in 3.4.0. The code is now correct. The patch that HJL posted at http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00838.html works, but he added that it is a temporary one and the solution would be the comdat group (which IMHO is not used with the patch)
Created attachment 6779 [details] Testcase, now syntactically correct
A patch which uses comdat group is posted at http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01047.html
*** Bug 16849 has been marked as a duplicate of this bug. ***
Bug 16849 has a much simpler test case.
Confirmed by Andreas then. As already noted, PR 16849 has a clearer description and smaller testcase.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01047.html
Another bug report: http://sources.redhat.com/bugzilla/show_bug.cgi?id=310 Could someone please comment on my patch? I'd like to see it in mainline, 3.3 and 3.4.
> Could someone please comment on my patch? I'd like to see it in mainline, > 3.3 and 3.4. SECONDED and REMINDER Important packages, notably Mozilla/Thunderbird/Firefox cannot be built with 3.3.4 or 3.4.1
> Could someone please comment on my patch? I'd like to see it in mainline, > 3.3 and 3.4. With your patch applied to gcc3.4.1, previously broken builds of Mozilla/thunderbird firefox are now working. But I am seeing similar looking problems (and failure) building Kdegraphics- 3.3.0 /bin/sh ../libtool --silent --mode=link --tag=CXX g++ -Wnon-virtual-dtor -Wno- long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align - Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 - Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new - fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT - DQT_NO_TRANSLATION -o libkpovmodeler.la -rpath /pkg/kde.1/lib - L/pkg/x11.1/lib -L/pkg/qt.1/lib -L/pkg/kde.1/lib -version-info 0:0:0 -no- undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined - R/pkg/freetype2.1/lib pmpart.lo pmfactory.lo pmview.lo pmshell.lo pmobjectdrag.lo pmtreeview.lo pmmessage.lo pmtreeviewitem.lo pmerrordialog.lo pminsertpopup.lo pminserterrordialog.lo pmglview.lo pmrendermanager.lo pmobjectselect.lo pmrendermodesdialog.lo pmpovrayrenderwidget.lo pmpovraywidget.lo pmpovrayoutputwidget.lo pmsettingsdialog.lo pmcolorsettings.lo pmgridsettings.lo pmlayoutsettings.lo pmobjectlibrarysettings.lo pmobjectsettings.lo pmpluginsettings.lo pmpovraysettings.lo pmpreviewsettings.lo pmopenglsettings.lo pmdockwidget.lo pmdockwidget_private.lo pmviewlayoutmanager.lo pmviewbase.lo pmviewfactory.lo pmunknownview.lo pmdragwidget.lo pmprototypemanager.lo pmobject.lo pmcompositeobject.lo pmgraphicalobject.lo pmsolidobject.lo pmscene.lo pmglobalsettings.lo pmskysphere.lo pmrainbow.lo pmfog.lo pmbox.lo pmsphere.lo pmblob.lo pmblobsphere.lo pmblobcylinder.lo pmtext.lo pmjuliafractal.lo pmcylinder.lo pmcone.lo pmtorus.lo pmplane.lo pmpolynom.lo pmdisc.lo pmbicubicpatch.lo pmtriangle.lo pmlathe.lo pmprism.lo pmsor.lo pmsqe.lo pmheightfield.lo pmheightfieldroam.lo pmcomment.lo pmraw.lo pmnamedobject.lo pmtranslate.lo pmscale.lo pmrotate.lo pmpovraymatrix.lo pmcsg.lo pmcamera.lo pmboundedby.lo pmclippedby.lo pmlight.lo pmlookslike.lo pmprojectedthrough.lo pmtexturebase.lo pmtexture.lo pmpigment.lo pmsolidcolor.lo pmlistpattern.lo pmquickcolor.lo pmpattern.lo pmblendmapmodifiers.lo pmtexturemap.lo pmnormal.lo pmslope.lo pmwarp.lo pmfinish.lo pminterior.lo pmmedia.lo pmmaterial.lo pmmaterialmap.lo pmdensity.lo pmimagemap.lo pmbumpmap.lo pmisosurface.lo pmradiosity.lo pmglobalphotons.lo pmphotons.lo pmlightgroup.lo pminteriortexture.lo pmspheresweep.lo pmmesh.lo pmdeclare.lo pmobjectlink.lo pmrecursiveobjectiterator.lo pmaddcommand.lo pmcommandmanager.lo pmdatachangecommand.lo pmdeletecommand.lo pmmovecommand.lo pmdialogview.lo pmdialogeditbase.lo pmgraphicalobjectedit.lo pmnamedobjectedit.lo pmsolidobjectedit.lo pmskysphereedit.lo pmglobalsettingsedit.lo pmrainbowedit.lo pmfogedit.lo pmboxedit.lo pmsphereedit.lo pmblobedit.lo pmblobsphereedit.lo pmblobcylinderedit.lo pmtextedit.lo pmjuliafractaledit.lo pmcylinderedit.lo pmconeedit.lo pmtorusedit.lo pmplaneedit.lo pmpolynomedit.lo pmheightfieldedit.lo pmlatheedit.lo pmprismedit.lo pmsoredit.lo pmsqeedit.lo pmdiscedit.lo pmbicubicpatchedit.lo pmtriangleedit.lo pmcommentedit.lo pmrawedit.lo pmrotateedit.lo pmscaleedit.lo pmtranslateedit.lo pmpovraymatrixedit.lo pmcsgedit.lo pmcameraedit.lo pmlightedit.lo pmboundedbyedit.lo pmclippedbyedit.lo pmlineedits.lo pmvectorlistedit.lo pmcoloredit.lo pmlinkedit.lo pmvectoredit.lo pmpalettevalueedit.lo pmformulalabel.lo pmtexturebaseedit.lo pmtextureedit.lo pmpigmentedit.lo pmsolidcoloredit.lo pmlistpatternedit.lo pmquickcoloredit.lo pmpatternedit.lo pmblendmapmodifiersedit.lo pmimagemapedit.lo pmtexturemapedit.lo pmbumpmapedit.lo pmmaterialmapedit.lo pmnormaledit.lo pmslopeedit.lo pmfinishedit.lo pmwarpedit.lo pminterioredit.lo pmmediaedit.lo pmmaterialedit.lo pmdensityedit.lo pmdeclareedit.lo pmobjectlinkedit.lo pmisosurfaceedit.lo pmradiosityedit.lo pmglobalphotonsedit.lo pmphotonsedit.lo pmlightgroupedit.lo pminteriortextureedit.lo pmspheresweepedit.lo pmmeshedit.lo pmcontrolpoint.lo pm3dcontrolpoint.lo pm2dcontrolpoint.lo pmsorcontrolpoint.lo pmtranslatecontrolpoint.lo pmrotatecontrolpoint.lo pmscalecontrolpoint.lo pmvectorcontrolpoint.lo pmdistancecontrolpoint.lo pmplanenormalcontrolpoint.lo pmmemento.lo pmmapmemento.lo pmsplinememento.lo pmprismmemento.lo pmpalettevaluememento.lo pmiomanager.lo pmpovrayformat.lo pmpovray31format.lo pmpovray35format.lo pmpovray31serialization.lo pmpovray35serialization.lo pmscanner.lo pmparser.lo pmxmlparser.lo pmpovrayparser.lo pmserializer.lo pmoutputdevice.lo pmxmlhelper.lo pmfiledialog.lo pmpalettevalue.lo pmvector.lo pmmath.lo pmmatrix.lo pmviewstructure.lo pmline.lo pmcolor.lo pmpoint.lo pmsymboltable.lo pmactions.lo pmsplinesegment.lo pmsorsegment.lo pmpolynomexponents.lo pmvariant.lo pmmetaobject.lo pmenumproperty.lo pmrendermode.lo pmresourcelocator.lo pmtruetypecache.lo pmdocumentationmap.lo pminsertrulesystem.lo pmlibrarymanager.lo pmlibraryhandle.lo pmlibraryhandleedit.lo pmlibraryobject.lo pmlibraryentrypreview.lo pmlibrarybrowser.lo pmlibraryiconview.lo pmlibraryobjectsearch.lo pmpluginmanager.lo pmpartiface_skel.lo -L/pkg/freetype2.1/lib -lfreetype -lz - lkparts -lGLU -lGL -lX11 -lXmu -lXi `.L82' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L85' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L88' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L91' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L94' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L97' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L106' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L109' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L112' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12setProtectedEP8PMObjectRK9PMVariant' of .libs/pmgraphicalobject.o `.L130' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12getProtectedEPK8PMObject' of .libs/pmgraphicalobject.o `.L133' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12getProtectedEPK8PMObject' of .libs/pmgraphicalobject.o `.L136' referenced in section `.rodata' of .libs/pmgraphicalobject.o: defined in discarded section `.gnu.linkonce.t._ZN10PMProperty12getProtectedEPK8PMObject' of .libs/pmgraphicalobject.o
any news on this problem? I've seen some problems like this one in OpenOffice.org cvs HEAD compilation with gcc-3.4.3 because of some inlined class methods at the cppu and the xmlscript modules.
I'm having the (NEARLY?) same problem, using gcc 3.4.3 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `typeinfo for CodeDOM::TAttribute'referenced in section `.gnu.linkonce.d._ZTVN7CodeDOM10TAttributeE' of .libs/TAttribute.o: defined in discarded section `.gnu.linkonce.d._ZTIN7CodeDOM10TAttributeE' of .libs/TAttribute.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `typeinfo for CodeDOM::TAttribute'referenced in section `.gnu.linkonce.d._ZTVN7CodeDOM10TAttributeE' of .libs/TAttribute.o: defined in discarded section `.gnu.linkonce.d._ZTIN7CodeDOM10TAttributeE' of .libs/TAttribute.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `typeinfo for CodeDOM::TAttribute'referenced in section `.gnu.linkonce.d._ZTVN7CodeDOM10TAttributeE' of .libs/TAttribute.o: defined in discarded section `.gnu.linkonce.d._ZTIN7CodeDOM10TAttributeE' of .libs/TAttribute.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `typeinfo for CodeDOM::TParamSym' referenced in section `.gnu.linkonce.d._ZTIPN7CodeDOM9TParamSymE' of .libs/TCastDef.o: defined in discarded section `.gnu.linkonce.d._ZTIN7CodeDOM9TParamSymE' of .libs/TParamSym.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `typeinfo for CodeDOM::TClassDef' referenced in section `.text' of .libs/TClassName.o: defined in discarded section `.gnu.linkonce.d._ZTIN7CodeDOM9TClassDefE' of .libs/TClassDef.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at elf32-i386.c line 2224 in elf_i386_relocate_section /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: Please report this bug. I first thought it would be a bug in binutils (ld), because he complained about. Is there any wayt to code around this bug? I'm forced to stop coding until this is fixed :(((
Please try the Linux binutils 2.15.94.0.1.
As a workaround, I just created a MyLibrary_all.cpp that #include'd all the .cpp files existing in this lib. this obviousely linked and I could work as usual (nearly).. However, I'm testing 2.15.94.0.1 now :) maybe thix fixes it. thanks, Christian Parpart.
Well, no. it doesn't work with that binutils: /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `typeinfo for CodeDOM::TClassDef' referenced in section `.gnu.linkonce.t._ZNK6System13Serialization18TSerializationInfo15getStrictObjectIN7CodeDOM9TClassDefEEEPT_RKNS_11TStringBaseIcEE' of .libs/TAttribute.o: defined in discarded section `.gnu.linkonce.d._ZTIN7CodeDOM9TClassDefE' of ./.libs/libCodeDOM_def.a(TClassDef.o) /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.15.94.0.1 20041121 internal error, aborting at /var/tmp/portage/binutils-2.15.94.0.1/work/binutils-2.15.94.0.1/bfd/elf32-i386.c line 2224 in elf_i386_relocate_section /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: Please report this bug. collect2: ld returned 1 exit status I would like to reproduce this within a little 2-file demo if would just know WTF this bug raises. I guess, giving you my sources doesn't help, does it? in order to find the bug, I mean. Greets, Christian Parpart.
This is a compiler bug. I am not sure how much linker can help here. A sel-contained testcase is needed to take a look at it.
Yeah, but I really do not know how to reproduce this bug, as the source code is really too much to say, line X is guilty. well, but what's "sel-contained"?
I don't mind a big testcase as long as it is all I need on a regular Linux installation.
I am having this same issue with my code. It's too large to commit but I will try and make a smaller test case out of it.
Has this bug been fixed yet? Would really like to upgrade my linux box, but can't because this bug prevents me from compiling a vital suite of software. Can we bump-up the priority? TIA Marc
also, not working with gcc-3.3.5, tested with linkoncedebug-0.0.1
May be is not gcc bug, but ld: the sample work with GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux, work with warnings with GNU ld version 2.15.94.0.2.2 20041220 (SuSE Linux) and don't work with ld 2.16.x (all with gcc 3.4.4).
We just ran into this trying to link a .a compiled with gcc-3.4.x against an app using gcc-4.0.1. Unfortunately, the .a is from a third party, so we can't share it or even look at the source ourselves. Here are a couple other posts which mention a similar bug. One of them almost has a simple test case. http://lists.debian.org/debian-mentors/2005/10/msg00316.html http://groups.google.com/group/de.comp.lang.iso-c++/msg/88f4ecd82239131c
testcase works for me with gcc-4.1.0-20051227 + binutils-2.16.91.0.5.
Test case doesn't work with gcc 3.3.6 and the latest cvs binutils (2.16.91.20051230)
(In reply to comment #24) > Test case doesn't work with gcc 3.3.6 and the latest cvs binutils > (2.16.91.20051230) > Testcase work when I used binutils 2.12.1. My OS box: Slackware 10.2 (i686)
Does anybody from gcc developers resolve this old bug issue at any finished time?! This is nearly 2 years old bug!!! Greets, Karol (In reply to comment #25) > (In reply to comment #24) > > Test case doesn't work with gcc 3.3.6 and the latest cvs binutils > > (2.16.91.20051230) > > > > Testcase work when I used binutils 2.12.1. > > My OS box: Slackware 10.2 (i686) >
Here's a relatively simple test case, in case anyone wants one, that reproduces either this problem, or a very similar one. It requires a mix of compilers, and of optimization selections, to reproduce, though. One gcc 3 compiler and one gcc 4 one should do it. $ cat foo.h class Foo { public: virtual ~Foo() {} virtual inline int f(int x) { switch (x) { case 0: return 0; break; case 1: return 1; break; case 2: return 2; break; // cases 0 to 2 bulk out the switch statement case 3: return 999; break; // cases 3 and 4 can be coalesced case 4: return 999; break; } return -1; } }; extern int g(int); extern int h(); $ cat lib1.cc #include "foo.h" int g(int i) { Foo f; return f.f(i); } $ cat lib2.cc #include "foo.h" int h() { Foo f; return f.f(0) + g(0); } $ cat main.cc #include "foo.h" int main() { return g(0) + h(); } $ ./g++-3.4.5 -Wall -W -pedantic -O2 -c lib1.cc $ ./g++-3.4.5 -Wall -W -pedantic -O0 -c lib2.cc $ ./g++-4.1.0 -Wall -W -pedantic -o main lib1.o lib2.o main.cc /path/to/i686-unknown-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN3Foo1fEi' referenced in section `.rodata' of lib2.o: defined in discarded section `.gnu.linkonce.t._ZN3Foo1fEi' of lib2.o ... and so on In this case, the ld in gcc 4.1 is version 2.16.1.
This test case *still* exhibits the failure using only g++ 3.3.6, and binutils 2.16.1: perry@honey:binutils-bug$ apt-show-versions g++-3.3 g++-3.3/testing uptodate 1:3.3.6-13 perry@honey:binutils-bug$ apt-show-versions binutils binutils/testing uptodate 2.16.1cvs20060413-1 perry@honey:binutils-bug$ cat GNUmakefile all: main clean: rm *.o lib1.o: lib1.C lib2.o: lib2.C main: main.C lib1.o lib2.o perry@honey:binutils-bug$ make clean all rm *.o g++ -c -o lib1.o lib1.C g++ -c -o lib2.o lib2.C g++ main.C lib1.o lib2.o -o main `.gnu.linkonce.t._ZN3Foo1fEi' referenced in section `.rodata' of lib2.o: defined in discarded section `.gnu.linkonce.t._ZN3Foo1fEi' of lib2.o collect2: ld returned 1 exit status make: *** [main] Error 1 perry@honey:binutils-bug$ (In reply to comment #27) > Here's a relatively simple test case, in case anyone wants one, that reproduces > either this problem, or a very similar one. It requires a mix of compilers, > and of optimization selections, to reproduce, though. One gcc 3 compiler and > one gcc 4 one should do it. > > > $ cat foo.h > class Foo { > public: > virtual ~Foo() {} > virtual inline int f(int x) { > switch (x) { > case 0: return 0; break; > case 1: return 1; break; > case 2: return 2; break; // cases 0 to 2 bulk out the switch statement > > case 3: return 999; break; // cases 3 and 4 can be coalesced > case 4: return 999; break; > } > return -1; > } > }; > > extern int g(int); > extern int h(); > > $ cat lib1.cc > #include "foo.h" > > int g(int i) { > Foo f; > return f.f(i); > } > > $ cat lib2.cc > #include "foo.h" > > int h() { > Foo f; > return f.f(0) + g(0); > } > > $ cat main.cc > #include "foo.h" > > int main() { > return g(0) + h(); > } > > $ ./g++-3.4.5 -Wall -W -pedantic -O2 -c lib1.cc > $ ./g++-3.4.5 -Wall -W -pedantic -O0 -c lib2.cc > $ ./g++-4.1.0 -Wall -W -pedantic -o main lib1.o lib2.o main.cc > /path/to/i686-unknown-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN3Foo1fEi' > referenced in section `.rodata' of lib2.o: defined in discarded section > `.gnu.linkonce.t._ZN3Foo1fEi' of lib2.o > ... and so on > > In this case, the ld in gcc 4.1 is version 2.16.1. >
(In reply to comment #28) > This test case *still* exhibits the failure using only g++ 3.3.6, and binutils > 2.16.1: Well 3.3.x is no longer being updated (likewise for 3.4.x).
Strange... I don't know why 3.3.x will not be updated. Currently line 3.3.x is used in many stable/production environments like stable: Debian (sarge), Slackware 10, Suse 10.
Just FYI, I attempted to compile Mozilla 1.8 using gcc 3.3.6 on a Fedora Core 5 system. I ran into this bug. The only patch in this bug that applies to 3.3.6 is the patch found in comment 0. With that patch applied to gcc the Mozilla build completed ok. I'm posting this comment using a Mozilla compiled that way.
Is the 3.3.x tree closed? If that is the case, should someone mark this bug WONTFIX, and those who care can move on patching their gcc or moving to a higher one? Has anyone reproduced this bug with a higher compiler version?
While trying to build some C++ code with g++-3.3.6 we encountered error messages similar to those mentioned in earlier comments in this discussion: `xxx' referenced in section `.rodata' of somefile.o: defined in discarded section `.gnu.linkonce.t._zzz' of something.o Searching for solutions to this error message led us to this gcc-bugzilla bug #16625 discussion. We were able to eliminate these error messages and successfuly compile our code with g++-3.3.6 by using the '-frepo' option in our g++ compiles. I understand that this may not be the ultimate solution to the bug(s) being discussed here, but since we ended up here when searching for this particular error message, I'm adding this comment in case it helps other people.
Could the be related to http://sources.redhat.com/ml/binutils/2004-08/msg00187.html? I'm getting those linker errors with both gcc 4.1.1 and gcc 4.1.2 on x86-Solaris with GNU ld from binutils-070227, but only when compiling with -O2 or -O3, but not with -O0. The referenced symbols shows up (gnm -a *.o) in several objects like this: 0000000000000000 t .gnu.linkonce.t._ZN10otl_streamlsEj 0000000000000000 W _ZN10otl_streamlsEj But in the object mentioned in the error messages like this: 0000000000000000 r .gnu.linkonce.r._ZN10otl_streamlsEj 0000000000000000 t .gnu.linkonce.t._ZN10otl_streamlsEj 0000000000000000 W _ZN10otl_streamlsEj One possible workaround is to reorder the objects during link, so that those with .gnu.linkonce.r.* come first. If this a compiler or a linker bug? (I'd blame the linker ;))
(In reply to comment #34) > Could the be related to > http://sources.redhat.com/ml/binutils/2004-08/msg00187.html? > > I'm getting those linker errors with both gcc 4.1.1 and gcc 4.1.2 on > x86-Solaris with GNU ld from binutils-070227, but only when compiling with -O2 > or -O3, but not with -O0. > > The referenced symbols shows up (gnm -a *.o) in several objects like this: > > 0000000000000000 t .gnu.linkonce.t._ZN10otl_streamlsEj > 0000000000000000 W _ZN10otl_streamlsEj > > But in the object mentioned in the error messages like this: > > 0000000000000000 r .gnu.linkonce.r._ZN10otl_streamlsEj > 0000000000000000 t .gnu.linkonce.t._ZN10otl_streamlsEj > 0000000000000000 W _ZN10otl_streamlsEj > > One possible workaround is to reorder the objects during link, so that those > with .gnu.linkonce.r.* come first. > > If this a compiler or a linker bug? (I'd blame the linker ;)) > It is most likely a Solaris specific compiler bug.
Subject: Re: Discarded Linkonce sections in .rodata >> One possible workaround is to reorder the objects during link, so that those >> with .gnu.linkonce.r.* come first. >> >> If this a compiler or a linker bug? (I'd blame the linker ;)) > > It is most likely a Solaris specific compiler bug. Erm, this bug was originally reported for i686-pc-linux-gnu, and none of the 33 previous comments refers to Solaris. Forgot to mention that the bug exhibits only with GNU ld, Solaris ld links fine without object reordering or other tricks. /Michael
(In reply to comment #36) > Subject: Re: Discarded Linkonce sections in .rodata > > >> One possible workaround is to reorder the objects during link, so that those > >> with .gnu.linkonce.r.* come first. > >> > >> If this a compiler or a linker bug? (I'd blame the linker ;)) > > > > It is most likely a Solaris specific compiler bug. > > Erm, this bug was originally reported for i686-pc-linux-gnu, and none of > the 33 previous comments refers to Solaris. > > Forgot to mention that the bug exhibits only with GNU ld, > Solaris ld links fine without object reordering or other tricks. > > /Michael > Can I reproduce it on Linux?
(In reply to comment #37) > > Can I reproduce it on Linux? > May be comment #21 help you?
(In reply to comment #38) > (In reply to comment #37) > > > > Can I reproduce it on Linux? > > > > May be comment #21 help you? > That is an old compiler bug which has been fixed since then.
Subject: Re: Discarded Linkonce sections in .rodata On Mon, 5 Mar 2007, hjl at lucon dot org wrote: > Can I reproduce it on Linux? Using gcc 4.1.1 with binutils-070227 I can also reproduce it on Linux, binutils 2.15 from Debian Sarge do not exhibit this problem. As this is a closes source application I can't upload the source code. Would the generated asm code be of any help? The smallest testcase I have is currently ~500k lines asm, split accross two files. /Michael
(In reply to comment #40) > Subject: Re: Discarded Linkonce sections in .rodata > > On Mon, 5 Mar 2007, hjl at lucon dot org wrote: > > > Can I reproduce it on Linux? > > Using gcc 4.1.1 with binutils-070227 I can also reproduce it on Linux, > binutils 2.15 from Debian Sarge do not exhibit this problem. > > As this is a closes source application I can't upload the source code. > Would the generated asm code be of any help? > > The smallest testcase I have is currently ~500k lines asm, split accross > two files. > > /Michael > Assembly files will help. Please make them available.
Created attachment 13152 [details] Testcase (generated assembly files from gcc 4.1.1)
(In reply to comment #42) > Created an attachment (id=13152) [edit] > Testcase (generated assembly files from gcc 4.1.1) > I got bash-3.1$ readelf -S -N fzotl.o | grep ZN10otl_streamlsEPKc [257] .gnu.linkonce.t._ZN10otl_streamlsEPKc [258] .rel.gnu.linkonce.t._ZN10otl_streamlsEPKc bash-3.1$ readelf -S -N fzconfig.o | grep ZN10otl_streamlsEPKc [338] .gnu.linkonce.t._ZN10otl_streamlsEPKc [339] .rel.gnu.linkonce.t._ZN10otl_streamlsEPKc [340] .gnu.linkonce.r._ZN10otl_streamlsEPKc [341] .rel.gnu.linkonce.r._ZN10otl_streamlsEPKc bash-3.1$ readelf -g fzotl.o fzconfig.o File: fzotl.o There are no section groups in this file. File: fzconfig.o There are no section groups in this file. bash-3.1$ It means your gcc 4.1.1 was built with a very old binutils and it doesn't support COMDAT group, which is needed to fix this bug. You have 2 choices: 1. Rebuild gcc 4.1.1 with the current Linux binutils. 2. Use a different Linux distribution with a proper gcc 4.1. FC6 is OK.
(In reply to comment #43) > It means your gcc 4.1.1 was built with a very old binutils and it doesn't > support COMDAT group Yes, this gcc was build with binutils 2.15 from Debian Sarge. Thanks
Created attachment 13157 [details] Patch to configure test for comdat support work with binutils snapshots gcc's configure test for COMDAT support seems to work only with regular releases but not with snapshots, where gld doesn't print a version number: $ gld -v GNU ld version 070227 20070227
Created attachment 13158 [details] Non-reversed patch to make configure test for comdat support work with binutils snapshots
(In reply to comment #45) > Created an attachment (id=13157) [edit] > Patch to configure test for comdat support work with binutils snapshots > > gcc's configure test for COMDAT support seems to work only with regular > releases but not with snapshots, where gld doesn't print a version number: > > $ gld -v > GNU ld version 070227 20070227 > It has been fixed in CVS: bash-3.1$ ./ld/ld-new -V GNU ld (GNU Binutils) 2.17.50.20070307 Supported emulations: elf_x86_64 elf_i386 i386linux
Solaris 10 x86 i386 gcc 3.3.6, binutils 2.17.50.20070307 has the same issue. binutils 2.17.50.20070307 not even compile under this platform. We have to modify some scripts to make it work.
The bug has been fixed by 2005-05-08 Julian Brown <julian@codesourcery.com> H.J. Lu <hongjiu.lu@intel.com> Paul Brook <paul@codesourcery.com> * configure.ac: Set ld_vers_major, ld_vers_minor and ld_vers_patch for GNU linker. Support linker version x.x.x.x.x. Require GNU linker 20050308/2.16.0 or newer for comdat group. * configure: Regenerated. * config.in: Regenerated. * varasm.c (default_function_rodata_section): Put .rodata section in COMDAT group when necessary. (default_elf_asm_named_section): Rename HAVE_GAS_COMDAT_GROUP to HAVE_COMDAT_GROUP. (default_unique_section_1): Don't use .gnu.linkonce when COMDAT is available. in GCC 4.1 or later.
For the archives: I have a backport of this for gcc 3.4.6 (actually, two commits 100490D02CD2CE90D8F and 10049E3533B275F48CB in MirBSD) because it affects being unable to build LLVM, too. Mail me if interested.
Created attachment 21888 [details] backported fix, diff’d against pristine gcc-3.4.6.tar.gz Because I’ve been approached by four or five people already about the backport of this fix to gcc 3.4.6 here’s the diff (since none of them reported whether it indeed helped them, as I had asked). My copyright assignment to the FSF stands, FWIW.
(In reply to comment #51) It still needs the following: --- gcc/config.in.comdat 2004-05-05 08:23:28.000000000 -0700 +++ gcc/config.in 2004-05-05 08:40:11.000000000 -0700 @@ -252,6 +252,9 @@ /* Define if your assembler supports .balign and .p2align. */ #undef HAVE_GAS_BALIGN_AND_P2ALIGN +/* Define 0/1 if your assembler supports COMDAT group. */ +#undef HAVE_GAS_COMDAT_GROUP + /* Define if your assembler uses the new HImode fild and fist notation. */ #undef HAVE_GAS_FILDS_FISTS (from http://gcc.gnu.org/ml/gcc/2004-05/txt00003.txt)
(In reply to comment #52) Sorry. It's regenerated by autoheader.