libgcc_s.so is unnecessarily linked for MIPS

[David Daney]

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/
> 
> 
> 
> David,
> Thanks very much for the reply. I tried with binutils 2.16.94 as well as
> 2.17.50.0.2, but the same problem persists. I suppose you are referring to
> the patch
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/elfxx-mips.c.diff?cvsroot=src&r1=1.146&r2=1.147 
> 
> .
> I observe that, this patch is already present in the both versions of
> binutils. I wonder, what else might be causing this problem.

Yeah, I don't understand it.  It works for my glibc build, so I thought 
it would work for uClibc as well.  But I just checked a recent 
buildroot/uClibc build and observe the same thing you are seeing.  I 
think it must be related to the '_gp_disp' symbol as it was for the 
glibc case, but there  must be some subtle difference in the way uClibc 
is linking.

I don't have time to fix it right now.  But I am planning on doing some 
more uClibc porting work in the next several months and I will take a 
look at then it unless someone else gets to it first.

David Daney.


David Daney.