Hacker News Reader

Comment by jclulow | Hacker News Reader

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.

View on HN

Build 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.

The suckless tools are recompile-to-reconfigure, so they don’t hit the length limitation of chrpath or fatal bugs in patchelf.

You wouldn't have a length limitation in using rpath just to express "find the libs near the executables, wherever those are".

If 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).

And 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).

They 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.

What advantage does sibling libs provide over static linking?

This 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.

Bundle the executables into a single larger mega-executable with symlinks as the “true” entrypoint name.

Meaningless question. Simetimes it's what you need. Sometimes it's not. Sometimes you want to write the arabic digit 3, sometimes you want to write the word three. What is the advantage of writing out three? The advantage is whatever the advantage is in those situations when you want it. The possible details are infinite.

All what work? Just adding -R '$ORIGiN' when linking the program will then cause it to look for shared libs in its own directory.

The program still looks for libc in the system directory.

The argument for this is that if you ship software that features multiple executables that share code, they can have it as shared libraries, and easily find it relative to their own location, just like on Windows.

Reply on news.ycombinator.com