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

[Jonathan Wakely]

On 21 June 2011 17:24, Jonathan Wakely <jwakely.gcc@gmail.com> 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.