Force absolute path for shared library without LD_RUN_PATH - g++

Question

I am trying to link a locally installed shared library (./vendor/lib/libfoo.so) with my binary, ./bar. Unfortunately, none of my attempts generates a link with an absolute path to libfoo.so. As a consequence I need to use
LD_LIBRARY_PATH=vendor/lib ./bar
to run it, which I want to avoid. ldd bar shows me this:
linux-vdso.so.1 => (0x00007ffed5fd8000)
libbar.so.2 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb9ea787000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb9ea47d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb9ea267000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9e9e9d000)
/lib64/ld-linux-x86-64.so.2 (0x000055f326761000)
A word about libbar.so.2: the file exists (in vendor/lib) alongside libbar.so. Both are actually symlinks to libhts.so.1.6. That file also exists, and is the actual shared library.
Here’s the different ways I’ve tried:
FULL_PATH="$(pwd -P)/vendor/lib"
g++ -o bar bar.o -Lvendor/lib -lfoo # 1
g++ -o bar bar.o -L$FULL_PATH -lfoo # 2
g++ -o bar bar.o $FULL_PATH/libfoo.so # 3
g++ -o bar bar.o $FULL_PATH/libfoo.so.1.6 # 4
All of these variants produce identical ldd output, even the last line (does ld insist on using the highest version of a library?).
The only way I’ve found to make this work is to use
LD_RUN_PATH=$FULL_PATH g++ -o bar bar.o -Lvendor/lib -lfoo
(I can’t use -rpath because my version of g++ doesn’t understand this argument, and I’m using g++ instead of ld to get the libstdc++ dependencies right — I could use -Wl,-rpath of course.)
But I can’t help but feel that there should be a way of making this work without the use of environment variables/-rpath. I’ve found an answer specifically referencing symlinks to libraries but unfortunately it doesn’t help me (see attempt 4 above).
This is on Ubuntu 16.04, g++ 5.4.0, GNU ld 2.26.1, in case it matters.

Answer 1

It sounds likely that you didn't update the ldconfig cache after installing
your shared library in the non-standard location /what/ever/vendor/lib:-
sudo ldconfig /what/ever/vendor/lib
Until you do that the runtime linker will be unaware that libfoo.so is
in /what/ever/vendor/lib, even if it is, unless you prompt it at runtime through
the LD_LIBRARY_PATH environment variable.
Incidentally, it isn't a shortcoming of your version of g++ that it
doesn't recognize -rpath. This has only ever been a linker (ld) option,
never a GCC frontend option. So -Wl,-rpath=/what/ever/vendor/lib is the
conventional way of tacking the non-standard runtime library path to your
program so as to avoid relying on either the ldconfig cache or LD_LIBRARY_PATH
For out-of-the ordinary linkages it may be considered better to use -rpath
rather than extend the ldconfig cache, which has less discriminate effects.