Hacker News Reader

Comment by jjnoakes | Hacker News Reader

> your friends can take your tarball and unzip it in any directory of their choosing. The whole prefix (environment) is self contained

How does this work if you are using ${PREFIX} with -rpath? I thought one had to use '$ORIGIN' to get a dynamic path that is relative to the executable's location. Unless conda is doing some '$ORIGIN' magic under the covers?

View on HN

If you use conda-build it will do rpath fixups for you. You can also elect to specify that certain dependencies should come from the system. We do this for X11 for the Anaconda Distribution. To use these, in the recipe you list `cdt` (stands for Core Dependency Tree) packages as build dependencies. These packages are repackaged CentOS6 library and devel packages that are never installed on end-users machines, only at build time.

Why not build with -rpath $ORIGIN/../lib etc? Wouldn’t that make the rpath fixups unnecessary? The whole tree should remain portable.

Well, the Anaconda Distribution and conda-forge build many thousands of packages and they use a variety of (often programmable) build systems.

So quite often the build system will be mis-programmed or will simply not care for relocatability at all, hard-coding /usr/lib/libfoo.so as DT_NEEDED, or hard-coding /usr/lib as DT_RPATH and/or DT_RUNPATH.

So conda-build runs a post-build step to make all DSO loading relative. We use patchelf and install_name_tool for that on Linux and macOS respectively.

> If you use conda-build it will do rpath fixups for you.

Interesting. I'm not a big fan of magic like that, but I'll check it out anyway.

The magic has a lot of similarities to how nix packaging works. Using patchelf for example. Both nix and the conda communities have been at this for years, so there are large user bases with several years of production battle testing behind the techniques we use. For reference, we estimate a current 6M+ Anaconda and conda client users.

Reply on news.ycombinator.com