Bug 16625

Summary: Discarded Linkonce sections in .rodata
Product: gcc Reporter: Fabian Wenzel <wenzel>
Component: c++Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: abominable-snowman, dank, dmlee, ebotcazou, gcc-bugs, gustavo.boiko, h.seki.95, hjl.tools, kaie, karol, mark, markus.glaser, matz, michael.klein, pawel_sikora, perry, rodolfo, schwab, tg, tim, trapni, uddeborg, zhong.xie
Priority: P2 Keywords: link-failure
Version: 3.4.0   
Target Milestone: 4.1.0   
Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu Known to work:
Known to fail: Last reconfirmed: 2004-08-01 15:10:16
Attachments: Testcase, now syntactically correct
Testcase (generated assembly files from gcc 4.1.1)
Patch to configure test for comdat support work with binutils snapshots
Non-reversed patch to make configure test for comdat support work with binutils snapshots
backported fix, diff’d against pristine gcc-3.4.6.tar.gz

Description Fabian Wenzel 2004-07-19 10:59:07 UTC
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)
Comment 1 Fabian Wenzel 2004-07-19 10:59:53 UTC
Created attachment 6779 [details]
Testcase, now syntactically correct
Comment 2 H.J. Lu 2004-07-19 13:40:12 UTC
A patch which uses comdat group is posted at

http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01047.html
Comment 3 Andreas Schwab 2004-08-01 09:31:32 UTC
*** Bug 16849 has been marked as a duplicate of this bug. ***
Comment 4 Andreas Schwab 2004-08-01 09:33:12 UTC
Bug 16849 has a much simpler test case. 
Comment 5 Giovanni Bajo 2004-08-01 15:10:16 UTC
Confirmed by Andreas then. As already noted, PR 16849 has a clearer description 
and smaller testcase.
Comment 6 H.J. Lu 2004-08-01 16:16:43 UTC
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01047.html
Comment 7 H.J. Lu 2004-08-07 16:41:27 UTC
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.
Comment 8 Andrew Walrond 2004-08-25 07:33:28 UTC
> 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
Comment 9 Andrew Walrond 2004-08-27 11:33:51 UTC
> 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
Comment 10 Gustavo Pichorim Boiko 2004-11-17 16:59:35 UTC
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. 
Comment 11 Christian Parpart 2004-11-23 09:19:14 UTC
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 :((( 
Comment 12 H.J. Lu 2004-11-23 16:40:02 UTC
Please try the Linux binutils 2.15.94.0.1.
Comment 13 Christian Parpart 2004-11-24 02:59:41 UTC
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. 
Comment 14 Christian Parpart 2004-11-24 03:19:16 UTC
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. 
Comment 15 H.J. Lu 2004-11-24 07:01:19 UTC
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.
Comment 16 Christian Parpart 2004-11-24 07:35:49 UTC
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"? 
Comment 17 H.J. Lu 2004-11-24 14:38:21 UTC
I don't mind a big testcase as long as it is all I need on a regular Linux
installation.
Comment 18 Brian Morey 2004-12-09 17:54:08 UTC
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.
Comment 19 Marc Price 2005-06-27 14:31:22 UTC
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
Comment 20 Markus Glaser 2005-08-30 08:23:15 UTC
also, not working with gcc-3.3.5, tested with linkoncedebug-0.0.1
Comment 21 Petr Ovtchenkov 2005-10-25 11:46:48 UTC
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).
Comment 22 dank 2005-11-18 18:19:04 UTC
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
Comment 23 Pawel Sikora 2005-12-30 10:24:40 UTC
testcase works for me with gcc-4.1.0-20051227 + binutils-2.16.91.0.5.
Comment 24 Karol Szkudlarek 2005-12-30 13:07:58 UTC
Test case doesn't work with gcc 3.3.6 and the latest cvs binutils (2.16.91.20051230)
Comment 25 Karol Szkudlarek 2005-12-30 13:30:39 UTC
(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)

Comment 26 Karol Szkudlarek 2006-04-04 09:00:58 UTC
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)
> 

Comment 27 simon_baldwin 2006-05-02 21:01:53 UTC
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.
Comment 28 Perry Kundert 2006-05-11 16:12:36 UTC
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.
> 

Comment 29 Andrew Pinski 2006-05-11 16:16:17 UTC
(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).
Comment 30 Karol Szkudlarek 2006-05-12 13:40:55 UTC
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.
Comment 31 Kai Engert 2006-09-22 16:57:25 UTC
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.
Comment 32 Hacksaw 2006-10-02 20:15:54 UTC
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?
Comment 33 Todd Pfaff 2006-12-29 17:40:02 UTC
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.
Comment 34 michael.klein@fazi.de 2007-03-02 16:25:07 UTC
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 ;))
Comment 35 H.J. Lu 2007-03-02 19:43:40 UTC
(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.
Comment 36 michael.klein@fazi.de 2007-03-05 08:43:16 UTC
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
Comment 37 H.J. Lu 2007-03-05 14:19:56 UTC
(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?
Comment 38 Petr Ovtchenkov 2007-03-05 14:53:09 UTC
(In reply to comment #37)
> 
> Can I reproduce it on Linux?
> 

May be comment #21 help you?

Comment 39 H.J. Lu 2007-03-05 15:25:59 UTC
(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.
Comment 40 michael.klein@fazi.de 2007-03-05 16:20:40 UTC
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
Comment 41 H.J. Lu 2007-03-05 16:38:31 UTC
(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.
Comment 42 michael.klein@fazi.de 2007-03-06 12:07:55 UTC
Created attachment 13152 [details]
Testcase (generated assembly files from gcc 4.1.1)
Comment 43 H.J. Lu 2007-03-06 15:27:30 UTC
(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.
Comment 44 michael.klein@fazi.de 2007-03-06 16:33:23 UTC
(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
Comment 45 michael.klein@fazi.de 2007-03-07 10:13:50 UTC
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
Comment 46 michael.klein@fazi.de 2007-03-07 10:20:10 UTC
Created attachment 13158 [details]
Non-reversed patch to make configure test for comdat support work with binutils snapshots
Comment 47 H.J. Lu 2007-03-07 14:33:22 UTC
(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
Comment 48 zhong.xie 2007-04-25 18:16:41 UTC
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.


Comment 49 Eric Botcazou 2007-09-07 07:08:44 UTC
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.
Comment 50 Thorsten Glaser 2010-04-03 18:18:20 UTC
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.
Comment 51 Thorsten Glaser 2010-09-26 14:03:31 UTC
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.
Comment 52 h.seki.95 2012-05-11 01:21:12 UTC
(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)
Comment 53 h.seki.95 2012-05-11 03:30:11 UTC
(In reply to comment #52)
Sorry. It's regenerated by autoheader.