Ld not finding library installed in /usr/local/lib

I’m working on building an application from source. After manually building one of the dependencies (chromaprint https://github.com/acoustid/chromaprint) it gets installed into /usr/local/lib:

    $ ls -lah /usr/local/lib/libchromaprint.so*
    lrwxrwxrwx 1 root root   19 May 27 08:44 /usr/local/lib/libchromaprint.so -> libchromaprint.so.1
    lrwxrwxrwx 1 root root   23 May 27 08:44 /usr/local/lib/libchromaprint.so.1 -> libchromaprint.so.1.4.4
    -rwxr-xr-x 1 root root 1.9M May 27 10:13 /usr/local/lib/libchromaprint.so.1.4.4

I’ve created a conf file under /etc/ld.so.conf.d:

    $ cat /etc/ld.so.conf.d/local.conf 
    /usr/local/lib 

However ld apparently still can’t find the library:

    $ ld -lchromaprint --verbose
    /snipped/
    ==================================================
    ld: mode elf_x86_64
    attempt to open /usr/x86_64-generic-linux/lib64/libchromaprint.so failed
    attempt to open /usr/x86_64-generic-linux/lib64/libchromaprint.a failed
    attempt to open /usr/lib64/libchromaprint.so failed
    attempt to open /usr/lib64/libchromaprint.a failed
    attempt to open /usr/lib32/libchromaprint.so failed
    attempt to open /usr/lib32/libchromaprint.a failed
    attempt to open /usr/lib/libchromaprint.so failed
    attempt to open /usr/lib/libchromaprint.a failed
    attempt to open /usr/x86_64-generic-linux/lib/libchromaprint.so failed
    attempt to open /usr/x86_64-generic-linux/lib/libchromaprint.a failed
    ld: cannot find -lchromaprint

Is there something I’m missing here in making sure ld is looking in /usr/local/lib as well? I guess it could also be an issue with the application I’m trying to build that it isn’t looking in /usr/local/lib…but that seems like an obvious place to include for dependency libraries.

Any help would be appreciated.

Read man stateless. It explains how to make applications see libraries in /usr/local:

echo "/usr/local/lib" | sudo tee -a /etc/ld.so.conf

Then run sudo ldconfig at least once.

1 Like

Yeah, so there should be no practical difference between putting the “/usr/local/lib” line directly in /etc/ld.so.conf, given that my ld.so.conf has the following:

/etc $ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf

However, I did as asked, so now it looks like this:

/etc $ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
/usr/local/lib

For good measure I ran ldconfig again:
$ sudo ldconfig

And, as expected, same as before (since nothing really changed about my ld config):

$ ld -lchromaprint
ld: cannot find -lchromaprint

So, why isn’t ld looking in the places its been told to?

 $ ld -lchromaprint --verbose
//snip
SEARCH_DIR("/usr/x86_64-generic-linux/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/lib32"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/x86_64-generic-linux/lib");
//snip
ld: mode elf_x86_64
attempt to open /usr/x86_64-generic-linux/lib64/libchromaprint.so failed
attempt to open /usr/x86_64-generic-linux/lib64/libchromaprint.a failed
attempt to open /usr/lib64/libchromaprint.so failed
attempt to open /usr/lib64/libchromaprint.a failed
attempt to open /usr/lib32/libchromaprint.so failed
attempt to open /usr/lib32/libchromaprint.a failed
attempt to open /usr/lib/libchromaprint.so failed
attempt to open /usr/lib/libchromaprint.a failed
attempt to open /usr/x86_64-generic-linux/lib/libchromaprint.so failed
attempt to open /usr/x86_64-generic-linux/lib/libchromaprint.a failed
ld: cannot find -lchromaprint

Clearly ld isn’t looking where I expect it to based on the configuration I have set. Is there something else that overrides or takes precedence?

So I read though the code this weekend and I can’t even find any reference to include being valid in the man pages for ldconfig and ld.so. This really surprised me so I ended up reading the actual glibc code to figure out whether include is even valid to begin with.

From what I can see, include is valid but I don’t see any code using glob or similar expanding wildcards. This confirms my suspicion that it’s the include word in the ld.so.conf file in your case that makes it just … not work at all.

Try removing the include line altogether and following the directions from man stateless - this does appear to work.

As for why this isn’t working - I don’t know yet. However it is certainly annoying and I’d even want /etc/ld.so.conf.d/*.conf to work without even having /etc/ld.so.conf to begin with, so I think this is going to take some investigation and patching to make this much more friendly…

Welp, I don’t know what is going on here, but, I have no issues doing this:

# cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
# cat /etc/ld.so.conf.d/local.conf 
/usr/local/lib
# ldconfig
# ldconfig -p | grep local
	libwhich.so.0 (libc6,x86-64) => /usr/local/lib/libwhich.so.0
<snip>

It… just works, sorry. (29690)

The simplest explanation is that you forgot to run ldconfig at some point… BTW, I would rely on ldconfig -p before ld -llib since that will produce many odd error messages if you’re not actually linking anything sane and help you debug the layer below the linker.

Except, as I showed above, I’ve run it a half dozen times since updating the config. I ran the commands in the order I showed in my above post, including running ldconfig right prior to trying to have ld find the library I’m looking for.

Anything else I should do to try to diagnose why it looks like my config isn’t getting picked up?

Yeah, I don’t know otherwise either.

You could inspect the output of ldconfig -p, as noted. You could remove the include line and just add the location of the libraries. Running ld -llib doesn’t actually do anything useful and will produce error messages even if lib is a valid library, so I would shy away from using that method to query the ld cache, especially since there’s a command made explicitly for it.

Is LD_LIBRARY_PATH set? If not, should it be?

There should not be a need to set LD_LIBRARY_PATH. You can, but it would be orthogonal to ld.so.conf.