Re: Linking against shared objects that reside at different paths on link-time versus runtime?

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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

> 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

> 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 ..