Re: Linking completely statically

On 10/08/2020 23.22, Tyson Whitehead wrote:

On Mon, 10 Aug 2020 at 03:12, Bardur Arantsson mailto:spam@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,