Are there any circumstances in which ld ignores LD_LIBRARY_PATH?

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.

Answer

Attribution
Source : Link , Question Author : John WH Smith , Answer Author : Stephen Kitt