Removing dependency to libgcc_s.so

David Daney ddaney at avtrex.com
Mon Jul 24 18:42:37 UTC 2006


Michael Hunold wrote:
>>>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?
> 

This is how it works.  The 64 bit division support is statically linked 
from libgcc.a

Although libgcc_s.so also contains the same support functions, it should 
only be linked if you are using exception handling.  The fact that on 
mipsel-linux-uclibc that it is unconditionally linked is a bug.

> 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.
> 

I'm quite confident that -static-libgcc will be the best solution short 
of fixing the linker.

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



More information about the busybox mailing list