Where is the missing library supposed to live?
For about a month, I was living with a constant stream of warnings whenever I ran a common command at work. While it didn’t make me less productive, since it didn’t affect any functionality I needed, it annoyed me and it bothered me that I didn’t know how to fix it the right way. The error I was getting was a warning about a dynamic library not able to be loaded even though the library existed on the system. Furthermore, when I ran `ldd` on the binary, the dynamic library wasn’t listed.
A quick hack was to find the library and set LD_LIBRARY_PATH to override the normal include paths. However, this didn’t work for automated scripts run from cron without some wrapper to set up the environment, and it felt very hacky anyway. What I wanted to do is find where the system was looking for the library that it couldn’t find so I could put the library in the right place (or at least set up a symlink).
Today, I decided to figure it out, and through some searching I came across this treasure trove that exactly explained the problem and the solution. Basically, the issue is that linux binaries (including libraries) have an rpath where they look for their shared objects. Setting LD_LIBRARY_PATH overrides this, but as I said, it’s a hack. To figure out the rpath, simply run:
readelf -d <path/to/binary> | grep RPATH
You can run this on any executable or library, so even if a library includes another library, you can just follow the path down until you find where the system is looking for the missing library and fix the problem.