Ldd Says "Not Found" Even Though Library Is in My Ld_Library_Path

ldd says not found even though library is in my LD_LIBRARY_PATH

The problem was a 32-bit/64-bit collision:

$ file libpmsfdcwrt.so
libpmsfdcwrt.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

$ file /lib64/libz.so.1.2.3
/lib64/libz.so.1.2.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Thank you, everyone, for pointing me in the correct direction.

ldd can't find library in LD_LIBRARY_PATH

The binaries I had were looking for the 32-bit versions of the shared libraries, I had the 64-bit installed. Stupid mistake. LDD didn't produce a very insightful error message, but the binary did when I tried to run it.

ldd says library isn't found by compile completes successfully

The library files are shared objects, which means that they will not be resolved until run time. In order for ldd to find them (assuming Linux or other Unix variant) you will need to add the path the libraries to your LD_LIBRARY_PATH (there is another path env that can be used but I can't think of it right now) and then ldd should be able to find the library.

ldd shows library not found for shared library dependency

I finally came across this question in which the answer provided by @schily worked for me.

QLibrary::load fails, but LD_LIBRARY_PATH just updated correctly before that, why?

The problem is that you change the environment variable LD_LIBRARY_PATH from within the process. However the process still uses the "old" environment variables block with old values. As a result it cannot properly find the dependent libraries and eventually fails.
Therefore your approach will not work. I would propose the following solutions:

• Set the LD_LIBRARY_PATH variable before starting the process, so that the process can take the updated block into account,
• Try to use QCoreApplication::setLibraryPaths() function to set the library search paths.

---

Related Topics