4 ms·

How does an article on NixOS talk about the `rpath` issue without also mentioning the `patchelf` utility that NixOS developers created to solve this issue? It's

How does an article on NixOS talk about the `rpath` issue without also mentioning the `patchelf` utility that NixOS developers created to solve this issue? It's a small tool that lets you modify ELF executables and binaries. It's also the recommended way for NixOS users to modify binaries to work properly. https://github.com/NixOS/patchelf https://github.com/NixOS/patchelf

kazinator 5y ago
I'm pretty sure NixOS isn't the only one doing this hack. The Yocto build system does something similar. It contains its own build-time binary glibc, and patches its tools to point to its own internal library installation. Or something like that. In effect, Yocto has its own build-time distro, which has to run from any filesystem location.
- PaulDavisThe1st 5y ago
  macOS has also been doing this for years, decades even, as part of the job of install_name_tool
  - astrange 5y ago
    Though you can override paths to libraries with environment variables, as long as the overriding one has the same full install name. That’s better since editing a binary will break its codesigning.
    - kazinator 5y ago
      Scripts and environment variables are an ugly hack. Environment variables are dynamically scoped and will cause problems, if you don't care to suppress them from being inherited by child processes. Suppose there are two installations of app. One is the system one, and one is locally installed by the user. The user overrides LD_LIBRARY_PATH when invoking the local app. Suppose that that app is used in such a way that it invokes the system-installed app; that could then find the wrong libraries due to the LD_LIBRARY_PATH being inherited. A program must simply know where its exact pieces are, all by itself, without any external tricks that could influence more than just that program. Search paths (all of them, including PATH) should be left to the user, for arranging the system; the user should be able to manipulate paths in arbitrary ways, yet the application shouldn't break as far as being able to locate and load its own pieces.
- lloeki 5y ago
  > I'm pretty sure NixOS isn't the only one doing this hack When developing ArchMac I had to do godawful hacks to bog-standard libs because whatever build system decided to hardcode a lib path (or forcefully strip one when it should be hardcoded, I've had to handle both) that I had to manipulate through various means including install_name_tool which is not that different from patchelf†. This kind of issue was not macOS specific, it just turns out the various ways things were built happened to gracefully "work" on most Linux distros by sheer luck but they could have been equally broken. † Not really a surprise when thinking about it, the concept of Nix derivations is not that different from the concept of Darwin bundles/frameworks (in terms of being a self-contained dependency package) so it's only natural similar issues, and thus approaches and tools to tackle them, emerged.
matklad 5y ago
`patchelf` solves a different problem: it fixes up an already built binary. Here, I am building the binary myself, so I’d rather make that just work without any extra build steps.
- slabity 5y ago
  Ah, my bad. I was confused because I never run into linker issues when I build my rust (or any other type of) binaries on a NixOS system. In fact, I am running the `evdev` example and I don't get any linker errors at all even when I change the linker to LLVM. I am using a nightly version of rust though.
- rubicks 5y ago
  Strongly concur. Patchelf is indispensible for beating sense into third-party closed-source shared objects. The `--set-soname` option is particularly useful in correcting all kinds of ineptitude.

kazinator 5y ago

I'm pretty sure NixOS isn't the only one doing this hack. The Yocto build system does something similar. It contains its own build-time binary glibc, and patches its tools to point to its own internal library installation. Or something like that. In effect, Yocto has its own build-time distro, which has to run from any filesystem location.

PaulDavisThe1st 5y ago
macOS has also been doing this for years, decades even, as part of the job of install_name_tool
- astrange 5y ago
  Though you can override paths to libraries with environment variables, as long as the overriding one has the same full install name. That’s better since editing a binary will break its codesigning.
  - kazinator 5y ago
    Scripts and environment variables are an ugly hack. Environment variables are dynamically scoped and will cause problems, if you don't care to suppress them from being inherited by child processes. Suppose there are two installations of app. One is the system one, and one is locally installed by the user. The user overrides LD_LIBRARY_PATH when invoking the local app. Suppose that that app is used in such a way that it invokes the system-installed app; that could then find the wrong libraries due to the LD_LIBRARY_PATH being inherited. A program must simply know where its exact pieces are, all by itself, without any external tricks that could influence more than just that program. Search paths (all of them, including PATH) should be left to the user, for arranging the system; the user should be able to manipulate paths in arbitrary ways, yet the application shouldn't break as far as being able to locate and load its own pieces.
lloeki 5y ago
> I'm pretty sure NixOS isn't the only one doing this hack When developing ArchMac I had to do godawful hacks to bog-standard libs because whatever build system decided to hardcode a lib path (or forcefully strip one when it should be hardcoded, I've had to handle both) that I had to manipulate through various means including install_name_tool which is not that different from patchelf†. This kind of issue was not macOS specific, it just turns out the various ways things were built happened to gracefully "work" on most Linux distros by sheer luck but they could have been equally broken. † Not really a surprise when thinking about it, the concept of Nix derivations is not that different from the concept of Darwin bundles/frameworks (in terms of being a self-contained dependency package) so it's only natural similar issues, and thus approaches and tools to tackle them, emerged.

matklad 5y ago

`patchelf` solves a different problem: it fixes up an already built binary. Here, I am building the binary myself, so I’d rather make that just work without any extra build steps.

slabity 5y ago
Ah, my bad. I was confused because I never run into linker issues when I build my rust (or any other type of) binaries on a NixOS system. In fact, I am running the `evdev` example and I don't get any linker errors at all even when I change the linker to LLVM. I am using a nightly version of rust though.
rubicks 5y ago
Strongly concur. Patchelf is indispensible for beating sense into third-party closed-source shared objects. The `--set-soname` option is particularly useful in correcting all kinds of ineptitude.