You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is often the case that closed-source binaries hard-code paths to global FHS locations. Currently, patchelf works for the very common case of ELF dependencies through shared linking but doesn't do much for other hard-coded paths like manual configuration lookup and even hard-coded dlopen calls.
It could perhaps be useful to be able to provide a "hard-coded path map" that would replace hard-coded paths from the text segment as well. This could allow changing such paths to relative-paths and then symlink the dependencies to the packaged nix packages directly.
This is much more flexible than wrapping executables using buildFHSEnv since it should work for MacOS as well (for which bwrap does not work) and would be leaner than running through namespacing.
The text was updated successfully, but these errors were encountered:
It is often the case that closed-source binaries hard-code paths to global FHS locations. Currently, patchelf works for the very common case of ELF dependencies through shared linking but doesn't do much for other hard-coded paths like manual configuration lookup and even hard-coded
dlopen
calls.It could perhaps be useful to be able to provide a "hard-coded path map" that would replace hard-coded paths from the text segment as well. This could allow changing such paths to relative-paths and then symlink the dependencies to the packaged nix packages directly.
This is much more flexible than wrapping executables using
buildFHSEnv
since it should work for MacOS as well (for which bwrap does not work) and would be leaner than running through namespacing.The text was updated successfully, but these errors were encountered: