4 ms·
The thing is, dynamic linking doesn't mean using LD_LIBRARY_PATH or building full blown OS packages as the only way to find the correct libraries. There's a fi
by jclulow 2y ago
The thing is, dynamic linking doesn't mean using LD_LIBRARY_PATH or building full blown OS packages as the only way to find the correct libraries. There's a first class facility for locating shared libraries, using the -R flag to provide a RUNPATH/RPATH in the binary. The runtime link editor will use that path to locate shared libraries. You can make your binaries relocatable as well, by using $ORIGIN in the RPATH: this gets expanded at runtime to the path of the executable, so, e.g., $ORIGIN/../lib would go up one from bin/ where the executable is and down alongside into the lib directory for your software.
LD_LIBRARY_PATH is a debugging and software engineering tool, and shouldn't ever be part of shipped software.
- fanf2 2y agoBuild systems often make it a huge pain to get the right rpath. The chrpath tool makes it easy to fix the rpath after libtool got it wrong.
- kazinator 2y agoIf you know that the executables will be in a certain directory, such that ../lib relative to that is where the libraries are found, then you just make the rpath '$ORIGIN/../lib'. That's it; no guesswork. Build systems that make it a huge paint to calculate elaborate rpath, e.g. knowing what the sysroot will translate to on the actual target system or whatever, are just doing counterproductive nonsense. By the way, I seem to recall that Yocto uses chrpath in order to get its own tools to reference its own copy of glibc that it provides (for itself, in the build environment).
- ttyprintk 2y agoThe suckless tools are recompile-to-reconfigure, so they don’t hit the length limitation of chrpath or fatal bugs in patchelf.
- kazinator 2y agoYou wouldn't have a length limitation in using rpath just to express "find the libs near the executables, wherever those are".
- vlovich123 2y agoAnd the main advantage of doing all that work vs statically linking is? Don’t get me wrong - dynamically linking for dev builds makes a lot of sense to cut down on relink times. But I just don’t see it for distribution since doing that RPath work reduces the main argument for dynamic linking (i.e. the OS can patch the vulnerability for all installed packages without waiting for each to release).
- Brian_K_White 2y agoThey didn't claim it was better than static. That doesn't make it worse than static either. They are two different answers for two different problems. It's simply that when you do want external but bundled neighboring libs, there is a good way to do it.
- vlovich123 2y agoWhat advantage does sibling libs provide over static linking?
- kazinator 2y agoThis becomes the same question as when and why are dynamic libraries useful over static linking! Suppose whatever you are shipping consists of five executables, which have a few hundred kilobytes of their own code and a 5 megabyte library. If they statically absorb the library, they all become 5.5 megabyte binaries. Adjust that to whatever sizes you would consider relevant. You can make it clear when a bug is fixed in a library or one of the executables. If you have a patch update, users can see that only a shared library changed or only a certain executable. When hunting a bug, you may have certain possibilities (within limits that depend on your library API maintenance), like trying an older executable with the same library, or older library with the same executable.
- vlovich123 2y agoBundle the executables into a single larger mega-executable with symlinks as the “true” entrypoint name.