[tlug] Static linking (try it at home!) [was: kernel update snafu]

["Stephen J. Turnbull" <stephen@example.com>]

Raymond Wan writes:

 > > AFAIR, you cannot statically link glibc. So you'll need 32-bit glibc.
 > > Basically if you can run other 32-bit software you should be fine.
 > 
 > Ah...I guess I never ran a 32-bit program on this system before.  And
 > I didn't know that you cannot statistically link to glibc.  I fed it
 > to "ldd" and it didn't report that.

I don't think that's strictly true.  Remember, a static library is
*not* a monolithic object file, but rather a bundle of objects each of
which will be added to the resulting binary "as needed" (ie, if an
entry point is referenced by a module already linked in the program).
So if all you want to do is use printf, you *can* statically link.

It's not even hard.  Eg, consider test.c:

#include <stdio.h>
#include <stdlib.h>
int main (int c, char *v[]) { printf("Hello, TLUG!"); exit(0); }

Then compile with "gcc -o dtest test.c", giving a binary of 8044 bytes,
dynamically linked (according to ldd) to linux-vdso.so.1, libc.so.6,
and /lib64/ld-linux-x86-64.so.2.  Runs fine, produces expected output.

Now compile with "gcc -static -o stest test.c", giving a binary of
973252 (!) bytes which is *not* dynamically linked (according to ldd),
but it runs fine, and produces expected output (on my system, YMMV).

N.B. file(1) agrees which is dynamic and which is static.  Stripping
the binaries slims (?) them down to 6216 and 750808 bytes, respectively.

ISTR that some components of glibc (IIRC nss, the Name Service Switch
is one) are not supposed to be linked statically for some reason.  In
glibc (it's specific to glibc), "nss" is not (just) the DNS, it's a
whole bunch of things where the system needs to map names to objects.
So for many programs you'll need to do some dynamic linking anyway.

Of course, glibc is free software; I'm sure it's *possible* to statically
link everything you need somehow, although you may have to compile the
glibc objects yourself and list them as .o files in the gcc command.

TLUG historical reference: Steve Baur claimed to have a collection of
statically linked Emacsen going back to Emacs 18.55, and bash or zsh
of similar age which still ran, without recompiling, on any Linux
system (on 32-bit x86 hardware, of course) as of 2007 or so.  That
meant he could boot a "useful" system with only two files: vmlinux and
xemacs (linked to "/sbin/init" :-).  ELispM, anyone?  (Didn't think
so, but hey, had to try!)