I've just come across a little problem with ld
which I just can't explain. Let's say I have compiled a library in my home directory and installed it all under ~/root
. The shared library file can be found at ~/root/usr/local/lib/libmylib.so
.
Because ~/root/usr/local/lib
is not in the linker's search path, I set LD_LIBRARY_PATH
as I always do:
LD_LIBRARY_PATH="$HOME/root/usr/local/lib"
export LD_LIBRARY_PATH
And check that the library is available with:
$ ls $LD_LIBRARY_PATH/libmylib.so
/home/me/root/usr/local/lib/libmylib.so
Now, if I run:
$ ld -lmylib --verbose
The final lines should include something like:
attempt to open /home/me/root/usr/local/lib/libmylib.so succeeded
-lmylib (/home/me/root/usr/local/lib/libmylib.so)
Except in my case, they don't. ld
simply does not perform any lookup under /home/me/root
. The contents of LD_LIBRARY_PATH
simply never appear in the output, which suggests that ld
is shamelessly ignoring the variable (and actually, my directory never appears in SEARCH_DIR
earlier in the output).
However, if I run:
$ ld -L $LD_LIBRARY_PATH -lmylib --verbose
I do get the above lines and everything goes smoothly, which means there's nothing wrong with the library or the installation path.
Is there any circumstance in which ld
ignores LD_LIBRARY_PATH
? I've checked env
and I couldn't find any other linker-related variable (RPATH
, LIBRARY_PATH
, LD_RUN_PATH
, which were all tested). Configuration under /etc/ld.so.*
does not appear to do anything except register some (other) directories. The machine runs Scientific Linux 7.4, gcc 6.4 and ld 2.25.1. The library in question is libxml++-3.0
.
Best Answer
As far as I know
ld
ignoresLD_LIBRARY_PATH
, at least for libraries specified on its command line;LD_LIBRARY_PATH
isn’t listed in the environment variables which affect it. It does refer toLD_LIBRARY_PATH
when looking for libraries which are needed by other libraries, in native builds, emulating the behaviour ofld.so
.