[BusyBox] Libc5 vs glibc-2 - Why the huge binary size differences?

Erik Andersen andersen at lineo.com
Mon Jun 19 21:01:00 UTC 2000


On Mon Jun 19, 2000 at 01:36:02PM -0700, Karl M. Hegbloom wrote:
> 
>  What makes glibc-2 linked binaries so much larger than libc5
>  binaries?

granularity.  When you statically link, the linker is able to throw away stuff
it finds that is unused.  For example if libc.a is composed of foo.o and bar.o,
but your app only uses functions defined in foo.o, and nothing from foo.o
references anything in bar.o, then the linker only links foo.o statically into
your app.

GNU libc is a horible maze of twisty dependanices, all alike.  If you
statically link the most trivial app against GNU libc (i.e. int main(void)
{return 0;} ) that app is still 200k+, because of all the dependancy baggage
that GNU libc carries along with it.  __exit pulls in malloc, which pulls in
multibyte char support, etc, etc.  Libc5 still pulls in a bunch of unwanted
crap, but it sure pulls in a lot _less_ unwanted crap.

In an ideal world (i.e. uC-Libc) every function is nicely independent of
everything else, and when you statically link, you only pull in what you need.
uC-Libc isn't ready for prime time embedded development yet on x86 (we just got
malloc working last week for example), but "Hello World" is 4k statically
linked.  That is the beauty of granularity.  You only get that by designing the
c library for it from the ground up.  GNU libc has other design goals, so IMHO
it will never be an ideal fit for embedded systems.  Of course, taking the
Moore's Law approach, one could just sit around doing nothing, and wait for
flash to get cheaper...  But that isn't nearly as much fun. :)

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--





More information about the busybox mailing list