Why I Cannot Override Search Path of Dynamic Libraries with Ld_Library_Path

Why I cannot override search path of dynamic libraries with LD_LIBRARY_PATH?

From http://man7.org/linux/man-pages/man8/ld.so.8.html

When resolving shared object dependencies, the dynamic linker first
inspects each dependency string to see if it contains a slash (this
can occur if a shared object pathname containing slashes was
specified at link time). If a slash is found, then the dependency
string is interpreted as a (relative or absolute) pathname, and the
shared object is loaded using that pathname.

If a shared object dependency does not contain a slash, then it is
searched for in the following order:

o (ELF only) Using the directories specified in the DT_RPATH dynamic
section attribute of the binary if present and DT_RUNPATH
attribute does not exist. Use of DT_RPATH is deprecated.

o Using the environment variable LD_LIBRARY_PATH. Except if the
executable is a set-user-ID/set-group-ID binary, in which case it
is ignored.

o (ELF only) Using the directories specified in the DT_RUNPATH
dynamic section attribute of the binary if present.

o From the cache file /etc/ld.so.cache, which contains a compiled
list of candidate shared objects previously found in the augmented
library path. If, however, the binary was linked with the -z
nodeflib linker option, shared objects in the default paths are
skipped. Shared objects installed in hardware capability
directories (see below) are preferred to other shared objects.

o In the default path /lib, and then /usr/lib. (On some 64-bit
archiectures, the default paths for 64-bit shared objects are
/lib64, and then /usr/lib64.) If the binary was linked with the
-z nodeflib linker option, this step is skipped.

• with readelf readelf -d libfftw3_mpi.so you can check if your lib contains such a attribute in the dynamic section.

• with export LD_DEBUG=libs you can debug the search path used to find your libs

• with chrpath -r<new_path> <executable> the rpath can be changed

modify ld library search path on cluster (no root access)

thank you very much for your suggestions. I found the issue and solved the problem. In essence, I needed these additional flags to configure:

sh ../gcc-6.5.0/configure --prefix=/home/xyz/ --build=x86_64-linux-gnu --enable-languages=c,c++,fortran --with-mpfr=/home/xyz/ --with-gmp=/home/xyz/ --with-mpc=/home/xyz/

These posts were helpful: 1, 2, 3

Thank you again for the time you have invested to help me.

LD_LIBRARY_PATH precendence and trouble with compiling

If anyone is still reading this, I engaged in some "personnel engineering" to solve the problem, i.e. got the system admins to re-install R so that it had everything I needed. Was certainly nice of them. Thanks very much to everyone who gave suggestions. Would like to keep going on some of them, but I've got to get busy on this project. Much obliged!

LD_LIBRARY_PATH vs LIBRARY_PATH

LIBRARY_PATH is used by gcc before compilation to search directories containing static and shared libraries that need to be linked to your program.

LD_LIBRARY_PATH is used by your program to search directories containing shared libraries after it has been successfully compiled and linked.

EDIT:
As pointed below, your libraries can be static or shared. If it is static then the code is copied over into your program and you don't need to search for the library after your program is compiled and linked. If your library is shared then it needs to be dynamically linked to your program and that's when LD_LIBRARY_PATH comes into play.

---

Related Topics