SDL_image error : cannot open shared object file: no such file or directory


I am a new NixOS user and I am facing a problem with SDL_Image.

What I am trying to accomplish

I need to compile a C project that makes use of SDL and SDL_Image libraries. So i created a default.nix at the root of my project.

with import <nixpkgs> {};

pkgs.mkShell {
    buildInputs = [

and then ran nix-shell. I successfully compiled the project. And when I try to run it (inside the nix-shell) there is this error that comes up :

Failed loading cannot open shared object file: No such file or directory

I tried multiple libjpeg packages available in nixpkgs but none of them worked. Is there something I am missing ?

Thanks for your help :slight_smile:

might be something todo with

where it was removed because it was broken.

is this a very old SDL project?

Thanks for your reply !

It is maybe 4 years old, but last time (3 weeks ago) I compiled it in archlinux and ran it in archlinux and it worked.

You can find in libjpeg_turbo package. libjpeg_original.out only has

1 Like

Thanks, I installed the libjpeg_turbo package and I had to exec

export LD_LIBRARY_PATH=/nix/store/cc2ha98f506jfgal0xwdwrnmxnr5imvd-libjpeg-turbo-2.0.3/lib

before running my project and it worked !

But I was wondering if there was a cleaner way to do this ? Maybe there is a way to specify the shared libs that we want to use in default.nix (nix-shell command would then populate the right env variables).

Thanks @jtojnar for your answer !

you can use

in the shell.nix file…

an example is here.

ah, my bad…you asked to set it default.nix… well groking nixpkgs…

there seems to be a few ways to do it, I’m not sure what’s the cleanest… or what the standard is…


this looks good to me… for example this uses lib.makeLibraryPath

LD_LIBRARY_PATH = lib.makeLibraryPath [ libX11 libXext libXfixes libusb1 udev bluez ];

and the export it in the preBuild part.

preBuild = ''

with nixpkgs, there’s about 3000 ways to skin a cat… groking it seems to a few ways of setting it, maybe it’s just older vs newer, or just personal style of those committers, or to coax the original build system (make/cmake/autoconf/pkgconf etc etc) into playing nice and behaving…

1 Like

Thanks, that did the trick :slight_smile:

I am marking this thread as resolved. Thanks everybody for your contributions.

1 Like