Solutions for `cannot open shared object file` errors

I’ve been enjoying NixOS a lot, and this has been the only thing that I’ve been struggling with.
While setting up shells for my projects, I have been frequently running into such errors with libraries.

Examples:
libfontconfig.so.1: cannot open shared object file: No such file or directory
libstdc++.so.6: cannot open shared object file: No such file or directory

It seems like there are many ways to fix this? I don’t know what I’m exactly doing but I usually mess around with LD_LIBRARY_PATH or solutions that other people have done until something ends up working. There are of course times where this approach ends up taking longer than it needs to.
I’d appreciate any resource I should know to solve these kinds of errors, or a general solution for them.
Thanks in advance.

You could try nix-ld (GitHub).

I think a minimal config is just:

programs.nix-ld = {
  enable = true;
  libraries = with pkgs; [
    # Put libraries that are required here
  ];
};

I didn’t even have to put any libraries in manually when I got this sort of issue, it sort-of just worked.

The solution depends on the ecosystem and toolchains available of your project.

Please share some more details. In most cases the solution is to set up your linker properly.

LD_LIBRARY_PATH or even nix-ld should be the last resort fallbacks, that only get used if there is really no tother way.

And especially for nix-ld, many consider it a very bad practice to configure its available libraries system wide.

1 Like

Sorry, should definitely have disclaimered this.

I (personally) don’t care for properly configuring things that break without it, I’d rather just get stuff done. If there is a best practice method that really isn’t a pain I’d consider it, but nix-ld works for me.

This doesn’t occur all the time, but it still happens frequently when I try compiling something.
It didn’t happen with a specific project, it has been happening on countless projects of mine. I don’t know if I can give more details.
Some libraries work well out of the box, but some just like to act that way I guess?

Is there a way to use this approach in a nix shell?

Sorry I must have skipped over this:

I think nix-ld is a bad solution for a development shell or building an application. I only use it to make other software work without having to spend my day figuring out why it doesn’t.

Are you saying you have fontconfig in the shell build inputs and are still getting this issue?

The libstdc++.so.6 comes from stdenv.cc.cc.lib too afaik.

As said, depending on the projects eco system, the solution might be different.

Come back with a couple of different examples, and eventually you will be able to transfer what you have learnt with these to new projects.

I’d actually say that using nix-ld with a mkShell-derived environment is pretty much the only sane way to use it. That way you’re not poisoning your entire system with untraceably scoped libraries, and actually still use NixOS as a proper nix-based distro.

But yeah, follow @NobbZ advice and come back with a proper example or two. Give it ~3-4 cases and you’ll have understood why, how, and what this error means, and be able to handle any future cases correctly (as well as maybe understand why nix-ld is such a problem).

2 Likes

True, however it makes sense for me until I can be bothered to write shells for all my projects. I don’t want to go far off topic, so I’ll leave it at that.

Will be following the thread either way as it might come in handy when I do decide to write shells for projects.

Apologies for the delay. I’m back now and I have an example to show.
Currently I’m trying to build Godot, and I’m getting these errors despite being in a shell with the libraries in the build inputs:

libfontconfig.so.1: cannot open shared object file: No such file or directory
libX11.so.6: cannot open shared object file: No such file or directory
libwayland-client.so.0: cannot open shared object file: No such file or directory
libz.so.1: cannot open shared object file: No such file or directory

The shell is structured like this:

pkgs.mkShell {
  buildInputs = with pkgs; [
    #...
  ];
}

This is the usual outcome whenever I try using shells this way.

Now, I do have a shell that I created which gets rid of some of those errors. It’s basically everything I could find online stitched together. This is what I’ve done inside of the shell:

shellHook = ''
  export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:${pkgs.freetype}/lib:${pkgs.alsa-lib}/lib:${pkgs.pulseaudio}/lib:${pkgs.xorg.libX11}/lib:${pkgs.xorg.libXext}/lib:${pkgs.xorg.libXcursor}/lib:${pkgs.xorg.libXrandr}/lib:${pkgs.xorg.libXinerama}/lib:${pkgs.xorg.libXi}/lib:${pkgs.xorg.libXfixes}/lib:${pkgs.xorg.libXrender}/lib:${pkgs.wayland}/lib:${pkgs.wayland-scanner}/lib:${pkgs.libxkbcommon}/lib:${pkgs.libdecor}/lib:${pkgs.mesa}/lib:${pkgs.libGL}/lib:${pkgs.vulkan-loader}/lib:${pkgs.fontconfig}/lib"
'';

This is insanely messy and I haven’t the slightest clue what I’ve done here, but this ends up fixing some of the errors I get?
Despite having this in the shell, the libfontconfig.so.1 error still persists.
What is being done here, and what should I do to optimally fix these errors while working in a shell?