When trying to build rust gui applications I get the error ‘error while loading shared libraries: cannot open shared object file: No such file or directory’
I have pkg-config and fontconfig installed and have tryed building using:

nix-shell -p pkg-config fontconfig freetype ftgl gperf pkgconf expat 

But still no luck…
Does anyone know how to solve?

1 Like

The exact same thing happened to me, I think I’ve figured it out (to an extent). Here’s what’s going on

When you run

nix-shell -p pkg-config

or the likes, you are most likely getting some sort of binary or application on your system, but sometimes (especially when compiling programs) you need the actual library (not the binary). On other repos, they usually have a convention of ending with -dev, -devel or starting with lib.

You’d install these libraries like you normally would (using nix-env or the configuration.nix if you will). The question is, “after installing these libraries how would the thing I’m compiling know that the library exists on my system?”. There are a few ways of answering this problem like nix-ld, but the approach I took was a slightly different one.

Here’s what I did:

 environment.variables = {
    LD_LIBRARY_PATH = with pkgs; lib.makeLibraryPath [
      # ...other libs

I added whatever library I need to the LD_LIBRARY_PATH environment variable (in my /etc/nixos/configuration.nix), and then run

 sudo nixos-rebuild switch

and then reboot to apply the changes.

I hope this helps

Installing libraries globally is not supported, see I installed a library but my compiler is not finding it. Why?.

Don’t use LD_LIBRARY_PATH environment variable. Or at least never set it globally. The paths listed in it take precedence over paths listed in DT_RUNPATH entry (the mechanism Nixpkgs use to link dependencies to ELF executables), which is dangerous. Sooner or later, you will run software built from a different version of Nixpkgs than your system and then you will get horrible crashes and symbol conflicts.

That is not right. While environment.systemPackages uses a default package output (that often lacks developement files), unless a different output is explicitly specified, nix-shell will generally make all relevant outputs available (including the library, the development files, and the executable programs).

This sounds more like the app tries to load using dlopen, not looking it up using pkg-config (though we would need to check the source code to be sure).

If it is the case, it will need to be patched to use the proper path, rather than trying to load it from global location:

1 Like

Yeah I saw something like this somewhere I think, I’m not saying that it’s a good way or anything, it’s just what I was able to get working on my end.

oh wow, I honestly didn’t know about this. Thanks for the clarification :smiley: