On 21 June 2011 17:24, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 21 June 2011 17:15, Dun Peal wrote: >> Hello! >> >> I have the following line in a build script: >> >> g++ [...] -Bdynamic /foo/bar.so >> >> This line results in a binary which when analyzed with `ldd(1)`, shows >> a dependency on `/foo/bar.so`. >> >> The problem is that the link-time and runtime platforms are not the >> same: at link-time, `bar.so` resides under `/foo`, while at runtime it >> lives under `/baz`. >> >> 1) Is there a way to link `bar.so` such that at compile (more >> precisely, link) time, it would be found at the former, while at >> runtime it would be found on the latter? > > 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. >> 2) The `ldd(1)` output for the binary shows some dependencies linked >> "literally", e.g. `/foo/bar.so`, while others have a notation like >> `libc.so.6 => /lib64/libc.so.6`. What's the difference? > > Some were linked with -l and some were named explicitly Or rather, some have a DT_SONAME, set by using -soname or by other methods. >> 3) Finally, is there a way to do runtime-platform-dependent links? >> Ideally, the runtime platform be able to tell the binary to look for >> `bar.so` under `/baz`. If that's not possible, being able to link >> relatively (`../bar.so`) or relative to an environment-specified >> location (`$HOME/qux/bar.so`) would be helpful. > > Use an RPATH, e.g. link with -Wl,-rpath,'/baz:$ORIGIN/..' will make it > look in /baz then in .. That bit's still true :) You can also use the LD_RUN_PATH environment variable when linking, instead of passing -rpath to the linker.
