I have an ARM embedded system running Debian Wheezy. Some of the functionality of our custom written apps is separated into shared library files. We store our shared library files under /usr/local/lib.
The problem I am seeing is that one of our binaries is not starting up correctly as it can't load one of the shared libs from /usr/local/lib:
/usr/local/bin/daemon_watchdog: error while loading shared libraries: libroots-base.so.5.3: cannot open shared object file: No such file or directory
The file libroots-base.so.5.3 exists in /usr/local/lib. /usr/local/lib should be getting searched for libraries, as we have added an extra file in the directory /etc/ld.so.conf.d/ to specifically include /usr/local/lib. I've also run ldconfig to refresh the cache.
One clue could be that the file libroots-base.so.5.3 itself depends on other shared libraries. If I run an "ldd libroots-base.so.5.3" in /usr/local/lib, it shows that several of the referenced libraries are not being picked up:
libboost_log.so.1.43.0 => not found
libboost_thread.so.1.43.0 => not found
libboost_system.so.1.43.0 => not found
libPocoUtil.so.11 => not found
libPocoFoundation.so.11 => not found
libPocoDataSQLite.so.11 => not found
libPocoData.so.11 => not found
libgthread-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgthread-2.0.so.0
(0x402f1000) libdbus-glib-1.so.2 => /usr/lib/arm-linux-gnueabihf/libdbus-glib-1.so.2 (0x4005c000)
However, the files listed as not found are definitely present in /usr/local/lib, e.g.
-rw-r--r-- 1 root root 821784 Nov 22 21:29 libboost_log.so.1.43.0
Furthermore if I manually set LD_LIBRARY_PATH to /usr/local/lib after the system has booted, I can run our binaries fine.
Can anyone suggest what could be wrong?
LD_DEBUG=alland see if the output contains any clues. (LD_DEBUG=helpmight be useful for reducing the output.) – scott