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.