libgcc_s.so is unnecessarily linked for MIPS

[Peter S. Mazinger]

On Wed, 14 Jun 2006, David Daney wrote:

> Erik Andersen wrote:
> > On Wed Jun 14, 2006 at 05:56:16PM -0700, David Daney wrote:
> >   
> >> As I said before, I am wondering also.  It works on a glibc system, and 
> >> is broken on a uClibc system.  Not to say that uClibc is causing it, but 
> >> there is a correlation.
> >>     
> >
> > Buildroot builds gcc with the '--enable-shared' option.
> >
> > $ ./configure --help | grep libgcc
> >   --disable-shared        don't provide a shared libgcc
> >
> > If you edit buildroot/toolchain/gcc/gcc-uclibc-3.x.mk
> > and tell it to use --disable-shared it will not use a
> > shared libgcc, but instead staticly link libgcc.a into
> > each app (which may or may not use any libgcc symbols).
> >
> >   
> While all that is certainly true, the simple hello world program should 
> be able to be linked with a tool chain configured with --enable-shared 
> *without* having a DT_NEEDED entry for libgcc_s.so.1.  That it does not 
> indicates that there is a bug somewhere in the tool chain.
> 
> do this : mipsel-linux-gcc -v -o hello-world hello-world.c
> 
> And you will see that in the linking stage, you have two instances of 
> '--as-needed -lgcc_s --no-as-needed'.  This tells the linker 
> (mipsel-linux-ld) to *only* set a DT_NEEDED for libgcc_s.so.1 *if* it is 
> required to resolve an undefined symbol in the hello-world executable.

wondering if this could be related to an --as-needed bug fixed in the past 
2 weeks in binutils-cvs

Peter

> If you run mipsel-linux-nm -D on hello-world, you will see that there 
> are no undefined symbols that can be resolved by linking libgcc_s.so.1, 
> so it is indeed unneeded.  The problem here is a bug in mipsel-linux-ld 
> that causes it to set DT_NEEDED
> tag for libgcc_s.so.1 when it is unneeded.
> 
> I encountered a seemingly identical  problem about a year ago with a 
> glibc based tool chain and thought I had fixed it.  That it still 
> appears in a buildroot/uClibc tool chain is unfortunate.  The proper 
> place to fix this is in the linker, not some configure hackery to work 
> around the problem.
> 
> That said, a short term work around would be to pass -static-libgcc on 
> the gcc command line when linking.  However if you have several programs 
> that all need a lot of the things in libgcc (like exception support or 
> floating point emulation), then it may be an overall win to use a shared 
> libgcc.
> 
> David Daney.
> 
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2