Where does Ubuntu look for shared libraries?

Question

When I run a process that links to a shared library at runtime (linked when the process starts, not linked later with dlload()), where does it look for that shared library (.so) file other than LD_LIBRARY_PATH?

Background:

I have some C++ code that I wrote that uses a particular third-party library. I have installed the library and compiled my code on two different platforms, both Ubuntu but different versions, and different versions of gcc as well. The library was compiled and installed from source, and is located in /usr/local/lib on both platforms. When I compile my code, I link with the pkg-config --libs parameters for the third-party library and I've verified that pkg-config --libs returns the exact same thing on both platforms.

My code compiles successfully on both platforms, and LD_LIBRARY_PATH is not defined (or defined as empty: "") on both platforms. However, when I run it on one platoform it works fine, and on the other I get this error:

error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory

Funnily enough, the ones that doesn't work is the newer version of Ubuntu and gcc. :/

So I'm trying to figure out how the working one is able to locate the library, so that I can make the broken one locate the library in the same way. (i.e., without setting LD_LIBRARY_PATH)

Update:

Here's my output from cat /etc/ld.so.conf.d/*

...on the working (older) system:

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

...on the broken (newer) system:

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa

Solution 1

This whole path business is related to something called multi-arch. Basically it's to allow you to have 32bit and 64bit libraries on the same system.

After you copied the file, did you happen to run ldconfig?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.

Solution 2

The information contained in the above question AND first (and only ATT) answer, helped me resolve *a similar * issue of mine on WSL Ubuntu (on Win10 64)!

In my case the executable couldn't find a library. I ultimately noticed that the newly-made library got positioned in /usr/lib64 , but the multi-arch lines of /etc/ld.so.conf.d/x86_64-linux-gnu.conf did not include that directory.

So I ran

sudo ldconfig /usr/lib64

and that finally fixed it. (running it alone without the directory parameter did not make it 'magically' find the libraries BTW.) It's unclear whether 'restarting' my WSL bash helped... I think that wasn't even needed.

Comments

[Dave Lillethun]

Seems like it, but see my update to the OQ for the contents of those files... So it looks like it should find /usr/local/lib/libthrift-0.9.0.so but still it gives the error error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... Is there any reason it would not pick up a directory from /etc/ld.so.conf.d/*.conf?

[geethujoseph]

Try to run sudo ldconfig -v as suggested below. If it still does not work update your question with the output of ldd /path/to/your/application.

[Dave Lillethun]

I ran sudo ldconfig and that fixed the problem! (Didn't need to recompile my code or anything...) I just want to understand, though... You said "After you copied the file," but I did not copy a file. Do you mean after I built & installed the library, or after I compiled my program?

[hookenz]

After you placed it where you placed it. Basically a library cache is built. I think rebooting may also rebuild the cache.

[Dave Lillethun]

I may be mistaken, but I believe I had rebooted since installing the library... However, sudo ldconfig did the trick. Is this something libraries often automatically run for your as part of their install, and this one for some reason didn't? Just wondering why I don't "normally" have to do this, but did only in this case...

[hookenz]

Usually the package install will run ldconfig during the install process I think. Maybe the version on your newer distro isn't doing it for some reason.

[Josh Milthorpe]

The same happened to me with /usr/local/lib/ . I created a file /etc/ld.so.conf.d/usr-local.conf and then ran sudo ldconfig with no effect - libraries in that dir were not found by the loader. After running sudo ldconfig /usr/local/lib everything worked fine.