Krdytkyu

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

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.

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.