libgcc_s.so is unnecessarily linked for MIPS

[Peter S. Mazinger]

On Wed, 14 Jun 2006, David Daney wrote:

> Peter S. Mazinger wrote:
> > On Wed, 14 Jun 2006, Kishore K wrote:
> > 
> > 
> >>On 6/13/06, David Daney <ddaney at avtrex.com> wrote:
> >>
> >>>>Dynamic section at offset 0x120 contains 26 entries:
> >>>> Tag        Type                         Name/Value
> >>>>0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
> >>>>0x00000001 (NEEDED)                     Shared library: [libc.so.6]
> >>>>
> >>>>AFAIK, none of the symbols of libgcc_s.so are required to be included in
> >>>>the
> >>>>above program. Then may I know, why is it dependent on libgcc_s.so.
> >>>>
> >>>>Same problem is observed with gcc-4.0.3 and various versions
> >>>
> >>>of  binutils (
> >>>
> >>>>2.15.94.0.2, 2.15.97, 2.16.91.0.7 & 2.17.50.0.2).  I am  using the
> >>>
> >>>latest
> >>>
> >>>>buildroot snapshot. The same problem is observed even with old
> >>>>uclibc-0.9.27based snapshots, when used for compiling tool chain based
> >>>>on
> >>>>gcc-3.4.4 and binutils 2.16.* and 2.15.*
> >>>>
> >>>>Any pointers to solve the above  problem would be appreciated.
> >>>>
> >>>
> >>>
> >>>
> >>>I fixed this in binutils CVS on Fri Jul 29 2005.  You need a binutils
> >>>CVS snapshot from after that date.  I would suggest a 2.17 pre-release
> >>>snapshot (perhaps 2.16.94) from
> >>>ftp://sourceware.org/pub/binutils/snapshots/
> > 
> > 
> > wondering how this is related to uClibc, you definitely linked against 
> > glibc
> > 
> 
> 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.
> 
> David Daney

You listed libc.so.6, so you havent linked against uClibc (that would show 
libc.so.0). I wouldn't wonder if the interpreter is ld-linux.so.2 as well

Peter 

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