Removing dependency to libgcc_s.so

Rob Landley rob at landley.net
Sat Jul 22 18:57:06 UTC 2006


Still at OLS, just scanning subject headers in my 81 back messages during a 
break between panels.  I hope to catch up on the drive back tomorrow...

On Friday 21 July 2006 8:56 am, Michael Hunold wrote:
> Hi,
> 
> I'm building busybox using a MIPS toolchain created by buildroot.
> 
> When building busybox as a dynamically linked application (which I want
> to do), there will be a dependency to libgcc_s.so.1, which is 274843
> bytes big. Not exactly what I call a leightweight.
> 
> busybox with my configuration is 187572 bytes.
> 
> I added "-nodefaultlibs -lm -lc" to the Makefile and ended up with
> unresolved symbols to __udivdi3 and friends.
> 
> I found out that these provide 64bit divison and modulo operations and
> are part of libgcc. Apparently they are used when the processor has no
> native 64bit division in hardware.
> 
> I added a straight-forward implementation to libbb and ended up with a
> busybox that is now 179204 bytes, so I saved 8368 bytes for the binary
> plus the complete libgcc that I don't need anymore.
> 
> Is removing the dependency to libgcc a good thing to do?

Yes.  What does your patch look like?

It's easy to detect this in platform.h, just do an "#if sizeof(long)==4" and 
if so, you need the fix because gcc is _stupid_ about this, and always has 
been.  This would be a good job for an always_inline function in platform.h, 
perhaps?

Ideally I'd like to make it so that the code itself can still just use normal 
division, so we want to provide an implementation of the gcc internal 
function.

> If so, I can provide a patch. But I'm not sure how to handle the case
> where busybox is built with a toolchain for a processor that has 64bit
> divison in hardware.

Let's see what you've got so far, ok?

> Best regards
> Michael Hunold.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list