Linking completely statically

[Bardur Arantsson]

On 10/08/2020 23.22, Tyson Whitehead wrote:
> On Mon, 10 Aug 2020 at 03:12, Bardur Arantsson <spam at scientician.net
> <mailto:spam at scientician.net>> wrote:
> 
>     Once you have that bit set up, you can copy *most* of the libraries
>     ..so's you're using to that folder on the install target and they'll be
>     loaded from there. (Copying libc.so is ill advised, but most of the
>     others will work just fine. I believe ld-linux-... is also never ever
>     loaded from there since that *is* the dynamic loader.)
> 
> 
> Not 100% certain, but I think the issue with libc may be that it may be
> somewhat tied to the ld-linux.
> 
> You can actually copy everything, including ld-linux, though. You then
> invoke the program via ld-linux (it's actually an executable -- see the
> ld..so page)
> 
> ./ld-linux-x86_64.so.2 --library-path <path to copied libraries>
> <executable> <args> ...
> 

Hm, yes I was vaguely aware of this ability to invoke the loader
directly, but IIRC the most immediate problem with glibc has always been
that the nsswitch.conf plugins (which are always dynamically loaded) are
strictly tied to the exact gblic version.

I guess if you copy them too, it should work, but the issue is that
there may be ones on the user's system which aren't present on the
CI/build system...

> If you wrap your binaries with a shell script it is actually pretty
> clean (make sure to exec so you don't windup with the shell sitting
> between parent and childs that can cause some subtle issues)

Yes, this is also a good way to do it and doesn't require messing with
the build setup.

> 
> The only real breakage I've seen from this is when you try and run on
> too old of a kernel for your libc or the remote system has an unusual
> nsswitch plugin you didn't provide.

Ack

Regards,