Removing dependency to libgcc_s.so

[David Daney]

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

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.

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

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


David Daney.