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

[Kalin KOZHUHAROV <me.kalin@example.com>]

On Fri, Jun 20, 2014 at 3:46 PM, Stephen J. Turnbull <stephen@example.com> wrote:
> 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.
>
No objections here, I did that a long time ago as a test. The answer
on some other ML was:
"No objections here, but this is a very limited example" ;-) ...

> 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.
>
Then this was as an additional explanation.

> 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.
>
May be, may be not. I am ready to pay anyone few beers who can compile
(static) current sleuthkit and related libs (64bit is priority, but
take 32bit as bonus):
http://www.sleuthkit.org/sleuthkit/download.php

I tried for an hour or so and gave up. It is something I use for work
occasionally, but I hate to be carrying a bunch of LD_PRELOAD with
me...

> 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!)
>
Not a Emacs user anymore, but sometimes it is good to have a couple of
static binaries that are dropped on a remote system via ssh and simply
work.

Cheers,
Kalin.