glibc

Posted Nov 3, 2005 4:44 UTC (Thu) by chant (guest, #20286)
Parent article: All hail the speed demons (O'Reillynet)

Some small part of this may be glibc bloat.

A 10 instruction AMD64 assembly program to
xor a register to 0
increment that register
exit when that register is 0 again

assembled to 731 bytes (not stripped of symbols/tables/etc).

When linked with gcc -static -o <progname> assembly.o
becomes
614,748 bytes.

That is incredible.

glibc

Posted Nov 3, 2005 11:44 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Here's the start of what happens with an empty file, simplifying where things start to explode.

A object file like

int main (void) { return 0; }

obviously pulls in nothing. But it gets linked with crtn.o, and then this happens (every object file except for crtn.o herein is in libc.a; things which do not lead to a size explosion omitted for clarity):

crtn.o:
 __libc_start_main
  libc-start.o:
  __cxa_atexit
   cxa_atexit.o:
    malloc
     malloc.o:
      fprintf, abort...
       [pulls in stdio, which pulls in libio, which pulls in i18n code, &c]

(There are other paths inside malloc() which also pull in stdio code, too).

The situation is basically unchanged since Zack Weinberg posted this post in 1999, except that changes in glibc since then mean that his solution won't quite work (you need to redefine __cxa_atexit()...)

Fixing it is difficult, and since everyone in the glibc team hates wasting time on static linking-related stuff that doesn't affect the common case of dynamically linked programs, it's not likely to happen soon.

glibc

Posted Nov 3, 2005 11:45 UTC (Thu) by nix (subscriber, #2304) [Link]

Oh, and of course none of this is true of dynamically linked programs and pretty much none of it is paged into memory for the vast majority of programs (whether statically or dynamically linked), so this explains no actual bloat at all.

glibc

Posted Nov 4, 2005 18:28 UTC (Fri) by oak (guest, #2786) [Link]

And note that Glibc cannot even produce really static binaries...
Name resolving and security stuff are always loaded dynamically.

However, it's silly to do static binaries with Glibc, you should use a C-library that's "designed" for that.
For example uClibc. :-)