Menu
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
822
Both rpath and runpath are used to specify directories to search for shared libraries(dynamic libraries). If you are not sure what shared libraries is, I have a story written on Static vs Dynamic libraries. Shared libraries are libraries which are not bundles along with the executable. They are loaded at the run time.
When a program linked with shared libraries runs, program execution does not immediately start with that program's first statement. Instead, the operating system loads and executes the dynamic linker (usually called ld.so), which then scans the list of library names embedded in the executable.
A shared object is an indivisible unit that is generated from one or more relocatable objects. Shared objects can be bound with dynamic executables to form a runable process. As their name implies, shared objects can be shared by more than one application.
A shared library or shared object is a file that is intended to be shared by multiple programs. Symbols used by a program are loaded from shared libraries into memory at load time or runtime.
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?
139
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
