4 ms·
You don't have to statically link, you can use LD_PRELOAD to point to local versions of all libraries. It isn't optimal, from space/security perspectives, but i
by angry_octet 8y ago
You don't have to statically link, you can use LD_PRELOAD to point to local versions of all libraries. It isn't optimal, from space/security perspectives, but it works. You can use the local libs first or last in the path.
- Spivak 8y agoYou don't even have to do that. When you compile your binary you just need to set the rpath to your own directory of libs and they will be search automatically and fall back to the system if missing.
- angry_octet 8y agoLast time I looked the rpath is a static absolute path, which is inconvenient if you want to install the libraries elsewhere. The automatic fallback to system libraries can also lead to mysterious problems.
- Spivak 8y agoThe linker recognizes a variable that expands to the location of the binary so you can use relative paths. ${ORIGIN}/lib will be the relative library path.
- angry_octet 8y agoFascinating. Some useful stack overflow answers on this topic. First, the trick to get GCC to pass the ORIGIN option to the linker: -Wl,-z,origin. Secondly, how to pass it as the rpath option: "-Wl,-rpath,'$ORIGIN' -- note that you need quotes around it to avoid having the shell interpret it as a variable, and if you try to do this in a Makefile, you need $$ to avoid having make interpret the $ as well." https://stackoverflow.com/questions/38058041/correct-usage-of-rpath-relative-vs-absolute https://stackoverflow.com/questions/38058041/correct-usage-o... The chrpath utility is also fascinating, as it allows you to rewrite the elf headers to change the rpath. Possibly better for installs than passing lots of env variables. Various warnings on this topic to not use actual relative paths unless you really want that behaviour.