Possible to enable nix-ld on a per-project basis? about nix-ld

[rupurt]

Would definitely love to figure out how to make this work on per project basis. For example I personally use home-manager. But most people on my team don't, and they don't want to do it either which I feel like is completely understandable.

[Mic92]

If you are doing buildFHSEnv, you are already getting /lib64/ld-linux-x86-64.so.2 based on the real glibc and you don't need nix-ld in the first place. So it doesn't make sense to replicate this behavior with nix-ld. I would say buildFHSEnv is the per project-based alternative to nix-ld.

[bonsairobo]

it doesn't make sense to replicate this behavior with nix-ld

buildFHSEnv does quite a bit more than just providing a global loader. It simulates an entire file hierarchy for binaries and libraries in the nix store. And as it's said in the README of nix-ld:

these sandboxes have their own weaknesses:

• setuid binaries cannot be executed inside a fhsuserenv
• inside a buildFHSUserEnv you can not use other sandbox tools like bwrap or 'nix build'.
• buildFHSUserEnv requires a subshell which does not work well with direnv

I couldn't say if any of these weaknesses are strictly a result of the per-project nature of buildFHSEnv, so I ask you to consider that.

So it would seem there is room for a per-project nix-ld to overcome the weaknesses of buildFHSEnv.

[Mic92]

You can enable NIX_LD_LIBRARY_PATH in your project's devshell. Is this not what you want?

[bonsairobo]

You can enable NIX_LD_LIBRARY_PATH in your project's devshell. Is this not what you want?

For this to have any effect, doesn't that require that nix-ld is already installed on your system?

[Mic92]

You can enable NIX_LD_LIBRARY_PATH in your project's devshell. Is this not what you want?

For this to have any effect, doesn't that require that nix-ld is already installed on your system?

Yes. But it needs to be. This is the tradeoff. I don't see how otherwise nix-ld would be made work.