On 21 June 2011 17:42, Dun Peal wrote: > On Tue, Jun 21, 2011 at 11:29 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >> On 21 June 2011 17:24, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >>> Rename it to libbar.so and link to it with "-L/foo -lbar" instead of >>> giving an absolute path to the .so >> >> Actually I think I've misremembered how it works, you might need to >> create bar.so using -soname=bar.so so that ldd will only make it >> depend on "bar.so" not the absolute path to the file, and will search >> for it in the usual locations. > > Thanks, unfortunately `bar.so` is a closed-source binary, and `-L/foo > -lbar` fails. That's because -lbar tells the linker to look for libbar.so or libbar.a, it won't find bar.so > Is there a way to know which `-soname` `bar.so` was assigned? Maybe on GNU/Linux: readelf -d bar.so | fgrep SONAME on Solaris use elfdump instead of readelf, there should be similar commands on other OSs I assume that won't return anything, if bar.so had a soname it would be used by ld instead of creating a dependency on the file's absolute path. > it's just different from `bar`, and if I just `-l<actual bar.so name>` > I'd be OK? That's not how it works. -lbar tells the linker to look for libbar.so, and if it finds libbar.so with a soname it creates a dependency on the soname, if it finds libbar.so without a soname it creates a dependency on the file's name, including the full path when you link to /foo/bar.so. So -lxxx can only match a file called libxxx.so (or libxxx.a), to do what you suggest it would have to open every single file and check if it has the requested soname, that won't work. >>> Use an RPATH, e.g. link with -Wl,-rpath,'/baz:$ORIGIN/..' will make it >>> look in /baz then in .. > > Thanks, but I take your answer to mean that I can't link relative to a > runtime target's environment variable (e.g. `$HOME`)? Correct, use LD_LIBRARY_PATH at runtime to do that.
