Reputation: 17186
On CentOS 7.2, I've built an app with g++ 4.8.5 that can't run because it can't find a library that does exist in its runpath
. I'm pretty sure it worked two weeks ago. What could cause this?
$ ./app
./app: error while loading shared libraries: libhdf5.so.9: cannot open shared object file: No such file or directory
$ ldd ./app | grep libhdf5
libhdf5.so.9 => not found
$ readelf app -d | grep path
0x000000000000001d (RUNPATH) Library runpath: [/opt/ProductName/lib:/opt/ProductName/lib/private]
$ ll /opt/ProductName/lib/libhdf5.so*
lrwxrwxrwx. 1 fotechd fotechd 16 Oct 26 14:38 /opt/ProductName/lib/libhdf5.so -> libhdf5.so.9.0.0
lrwxrwxrwx. 1 fotechd fotechd 16 Oct 26 14:38 /opt/ProductName/lib/libhdf5.so.9 -> libhdf5.so.9.0.0
-rwxr-xr-x. 1 fotechd fotechd 3316074 Oct 26 14:35 /opt/ProductName/lib/libhdf5.so.9.0.0
Setting LD_LIBRARY_PATH
fixes it temporarily:
$ LD_LIBRARY_PATH=/opt/ProductName/lib ./app
...
OK
Upvotes: 11
Views: 4268
Reputation: 851
In order to find the shared objects, dlopen() searches the following, in this order:
It seems dlopen()
does not check on RUNPATH
.
http://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrino_lib_ref/d/dlopen.html
Upvotes: 0
Reputation: 1555
I have been able to solve this issue on my side. For me it was because the not found library was an indirect one and runpath
actually does not resolve indirect dependencies. I fixed it with using rpath
instead of runpath
by passing the additional -Wl,--disable-new-dtags
linker option to the compiler.
There is a good and detailed explanation here: How to set RPATH and RUNPATH with GCC/LD?
Upvotes: 13