Paths are typically kept absolute, so garbage collection works. In order to support a relocatable store (chroot stores aren’t always of interest or possible), we would need to replace paths such as /nix/store/<hash>-<name>/lib/libfoo.so with $ORIGIN/../../<hash>-<name>/lib/libfoo.so. In this example I consider only binaries in $out/.bin, but it goes for every type of object storing a path. Since the hash will still be included in paths, Nix would still have sufficient information for garbage collection. Has anyone tried this?
Do relative shebangs work?
Relocatable stores would be amazing. In addition to binary rpaths, we often generate abspath symlinks too, though, e.g. ln -s $out/foo blah. Those would have to be cleaned up. Curious if anyone’s tried the relocatable route.
One thing I have tried that does work without any issue is relocating the entire store to an arbitrary directory, with complete rebuild from source and no binary cache. But it takes hours to do that first build!
1 Like
env could be used as interpreter. With -S you can pass multiple strings, circumventing the kernel limitation. env would be impure.
We also have paths embedded in binaries (e.g. paths to configuration files, data in share, etc.).
I’m interested in this; I think this could be a pretty big deal for Nix on HPC.
I wonder if it would be useful for testing to use a custom nix store location with a baked-in hash, like /nix-12345678123456781234567812345678/store. Then we could use the built-in disallowedReferences functionality to globally forbid references to 123456781234567812345678, guaranteeing that all store paths are relocatable.
3 Likes
I was investigating this topic as well, but noticed a pretty fundamental issue: PT_INTERP, i.e. the path to ld.so, does not support $ORIGIN on Linux. It supports relative paths, but those are relative to the current directory, not the executable. So it seems impossible for a dynamically linked executable compatible with the sandbox (i.e. using an ld.so from the store) to be truly relocatable.