libgcc_s.so is unnecessarily linked for MIPS

[David Daney]

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.

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.