Removing dependency to libgcc_s.so

Rich Felker dalias at aerifal.cx
Sat Jul 22 01:19:49 UTC 2006


On Fri, Jul 21, 2006 at 08:26:38AM -0700, David Daney wrote:
> 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?

IMO no. In my libc implementation I already rm libgcc and replace it
with tiny code in libc. Applications like busybox should not be using
low level hacks to work around whatever the system does.

If a particular user wants to disable the dependency on libgcc_s, all
they need to do is tell gcc to use the static libgcc (in which case
only the needed functions will be linked) or add -lfoo to their
LDFLAGS (where libfoo.a is a library replacing the needed functions
from libgcc). There's no need for BB to do this for them and create
extra nasty layers of low-level hacks.

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

Nonsense. These functions will never change because (a) there's only
one natural interface for them, and (b) all existing binaries depend
on the abi. The "tightly coupled with the compiler" stuff is a myth
perpetuated by the gcc developers with an agenda for C++.

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

I don't see how this is a bug in ld... The bug is in gcc for filling
libgcc_s with useless broken crap that's only for C++. There's
absolutely no reason for libgcc to be shared unless you use C++; the
only things from libgcc that are needed for C code are some support
functions for integer sizes bigger than system word size, and possibly
some floating point support functions (or all floating point functions
for soft float targets).

Rich




More information about the busybox mailing list