On 09/08/2020 14.50, Volker Wysk wrote:
Hi!
I know of the command line argument "-static". But this only affects the Haskell libraries. I want to link some programs completely statically, no external libraries needed.
When just linking with "-static" I still have those dynamically linked things:
desktop ~/bin $ ldd sicherung linux-vdso.so.1 (0x00007ffdab53f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3633da0000) [--snip--] libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f3633ce3000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f3633cd7000) libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f3633ccb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3633ad9000) /lib64/ld-linux-x86-64.so.2 (0x00007f3633f0c000)
Is it possible to link the remaining libraries statically too?
As Brandon already mentioned, linking glibc statically is not really supported (by glibc!), but what you can do is bundle a few of the .so's together with your binary and use RPATH to help your executable find them at load time (well, dynamic link time). A project of ours where we do this is using Stack, so I can only really provide info on doing it with Stack, but hopefully you can adapt to whatever you're using: We added ld-options: - -Wl,-rpath,$ORIGIN/../lib to the 'executable' portion of the package.yaml. This instructs the dynamic loader to look for libraries in '../lib' relative to the executable's location. You can pick whatever path you want there. 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.) (Of course a possibly more robust version of this is to just bundle everything into a container of some sort, but that may be a bit excessive for your needs.) HTH,