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