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
