mkShell, curl and LD_LIBRARY_PATH

I’m working on a Ruby project that uses Typhoeus as a developer. The project doesn’t come with Nix files, so I have added a flake.nix with mkShell. Typhoeus tries to load, but fails, because it cannot find the file.

I added curl to buildInputs, but this only adds the curl cli. I tried curl.lib, but this attribute didn’t exist. curl.out does exist, but it didn’t supply LD_LIBRARY_PATH.

Eventually I added LD_LIBRARY_PATH = [ "${curl.out}/lib" ];. This worked fine.

However, I’m wondering whether this is the way things should be working? I expected curl.lib to exist, but it didn’t. I expected LD_LIBRARY_PATH to be set by mkShell when using buildInputs, but it wasn’t. Am I doing this all correctly?

I myself had the same kind of error with multiple rust relying on the LD_LIBRARY_PATH. Maybe LD_LIBRARY_PATH should also be automatically set with mkShell (and migth be a good addition to nixpkgs).

1 Like

That makes sense, but I’m guessing that is hard to implement if packages like curl doesn’t have a curl.lib and the curl doesn’t have a /lib. Or should such packages always use curl.out, which does have a /lib?

Not setting LD_LIBRARY_PATH is usually the right choice because usually the native binaries find their libraries using RUNPATH which is specific to the binary. Setting LD_LIBRARY_PATH has an obvious problem of potentially messing up other programs.

For things like scripting languages though, not having LD_LIBRARY_PATH set presents a problem because they find the library from essentially a runtime string…

Not sure how to solve this, just some details of the problem.

Yes, that seems to be the convention. There’s a helper function lib.makeLibraryPath that (IIUC) implements this convention.


Thanks @dramforever @bobvanderlinden - this helped me work around an issue and learn about lib.makeLibraryPath