Removing dependency to libgcc_s.so

Michael Hunold hunold at linuxtv.org
Mon Jul 24 18:31:54 UTC 2006


Hi David,

on 24.07.2006 18:06 David Daney said the following:
> Michael Hunold wrote:
>> Hello David,
>>
>> on 21.07.2006 17:26 David Daney said the following:
>>
>>> The proper way to fix this is to fix the toolchain.  The implementation
>>> of the functions in libgcc are tightly coupled with the compiler and
>>> should be left where they belong (in libgcc).
>>>
>>> All you are doing is papering over a bug in ld.  Best to fix it there. I
>>> would refer you to this e-mail thread which discusses the problem a bit:
>>>
>>> http://www.uclibc.org/lists/uclibc/2006-June/015630.html
>>
>>
>> Hm. The discussion thread is about an application that is unnecessarily
>> linked to libgcc due to a presumed toolchain bug.
>>
> 
> The bug is real.  It bit you didn't it?

I believe you that there is the problem in the toolchain. But to be
honest, I don't know if it applies to my problem here really.

>> I don't claim that this is the case for busybox, 64bit arithmetic is
>> definately used there, so the linkage to libgcc is needed.
>>
> 
> Correct.  But you were complaining about a DT_NEEDED for libgcc_s.so,
> which is different than libgcc.a.

I used "-nodefaultlibs -lm -lc" and then the linker was complaining
about missing references to udivdi3() and friends.

> If you look (with nm -D) at your executable and libgcc_s.so, you will
> see that there are no undefined symbols that can be satisfied by
> libgcc_s.so.

When I provided these
functions, then the linking succeeded and I was able to run the
application, without libgcc_s.so being present on my system. ldd showed
no reference to libgcc_s.so any more. Is this what you mean?

>> So it is more about getting rid of libgcc, even though it is needed. As
>> suggested, this can either be done by directly replacing the functions
>> (ie. __divdi3) or by providing substitutes (ie. div64()).
> 
> What you want is to get rid of libgcc_s.so, not the statically linked
> libgcc.a.  Since the linker bug is biting you, I would suggest linking
> with -static-libgcc instead of the contortions that you are using.

I'm confused now. Is 64bit division now part of libgcc_s.so or is gcc
supposed to statically link in the stuff from libgcc.a even though the
application is dynamically linked?

Thanks for your suggestion, I'll try -static-libgcc tomorrow and see
what the result is. If this works, everything else is probably not worth
the effort.

> Re-implementing the proven code in libgcc although fun, is not
> particularly useful.  The time would be better spend fixing the linker.

8-)

> David Daney.

Best regards
Michael.



More information about the busybox mailing list