I’m investigating a curious case of a cursed Fedora.
We have a nix develop dev shell that mostly comes down to compiling Rust code. Everything is locked via flake and should not depend on the host system.
Everything works for everyone, Linuxes, NixOSes, MacOS, except one co-worker who is getting:
target/debug/deps/project-7771421b8e34f40b: error while loading shared libraries: libsnappy.so.1: cannot open shared object file: No such file or directory
and other shared libraries (mostly OpenSSL) not being found.
The box is Fedora 37, which later updated to 38.
We used env HOME=$HOME/subhome nix develop --ignore-environment .. to isolate it from the host as much as possible. No change. It suggests it’s something introduced by the host system, not the user setup.
We were able to point to:
[coworker @fedora project](master)$ readelf -d target/debug/deps/project-7771421b8e34f40b | grep runpath
0x000000000000001d (RUNPATH) Library runpath: [/home/coworker/workspace/project/outputs/out/lib64:/home/coworker/workspace/project/outputs/out/lib]
while on the normal system it is:
> readelf -d target/debug/deps/project-7771421b8e34f40b | grep runpath
0x000000000000001d (RUNPATH) Library runpath: [/home/dpc/lab/project/project/outputs/out/lib64:/home/dpc/lab/project/project/outputs/out/lib:/nix/store/i57qjfacl3hv7sc1s1lj4z6fssh69nd3-openssl-3.0.11/lib:/nix/store/gr71m95ks4ahhmal59n60jm3vhy6yzd6-snappy-1.1.10/lib/:/nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib:/nix/store/81d13il7plchw65gz8y9ywcxrngq149c-gcc-12.2.0-libgcc/lib]
The rustc invocation creating this binary is the same on all machines (verified with cargo -vvv ...).
Does anyone have any ideas what could it be? What setting on the system itself could make binaries come out with a wiped rpath?