Some proprietary software don't like their binaries modified. There are some workarounds, some even include patching binary files (!). This doesn't feel sustainable.
For rpath/runpath, LD_LIBRARY_PATH should be able to replace them. But we still have to set the dynamic linker somehow. I tried running the program from the dynamic linker (ld.so program), but this results in /proc/self/exe pointing to ld.so instead of the program, which breaks programs that exec themselves.
So the only other solution (well, other than using an fhs env) I can think of is to have the nix stub-ld load the real ld.so. i.e. designate an environment variable such as NIX_LD_SO for storing the real ld.so, read that in the stub-ld and run it.
Not sure how doable this would be. There are some details of how dynamic linkers work I am unsure about.
Issue description
This is inspired by #195512
Some proprietary software don't like their binaries modified. There are some workarounds, some even include patching binary files (!). This doesn't feel sustainable.
For rpath/runpath,
LD_LIBRARY_PATH
should be able to replace them. But we still have to set the dynamic linker somehow. I tried running the program from the dynamic linker (ld.so program
), but this results in/proc/self/exe
pointing told.so
instead of the program, which breaks programs thatexec
themselves.So the only other solution (well, other than using an fhs env) I can think of is to have the nix stub-ld load the real
ld.so
. i.e. designate an environment variable such asNIX_LD_SO
for storing the realld.so
, read that in the stub-ld and run it.Not sure how doable this would be. There are some details of how dynamic linkers work I am unsure about.