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 27 June 2011 17:19, Dun Peal <dunpealer@gmail.com> wrote:
> On Tue, Jun 21, 2011 at 12:06 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> -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.
>
> Just to make sure I understand: you are saying that with `-L/foo
> -lbar`, ld is going to look for `libbar.so` inside `/foo`, check if it
> has an soname, and if it does: link to it.

No, not quite.

It's going to look for libbar.so or libbar.a in /foo and then the
standard library directories (eg. /usr/lib) and use the first
libbar.so or libbar.a it finds, regardless of whether it has a soname.

See http://www.oracle.com/technetwork/articles/servers-storage-admin/linkinglibraries-396782.html

If it finds a shared library libbar.so (as opposed to an archive
libbar.a) then the executable will be dynamically linked to the shared
library and will have a dependency on that shared library.  If that
happens, the dependency will use the shared library's soname if it has
one, otherwise it will use its filename.


> But how is it going to find the library with the same soname at
> runtime? ?Will it have to open every `lib*` file in the load path
> (i.e. the system default + LD_LIBRARY_PATH) and look at its soname?

No, the soname specifies the filename the runtime linker will use, so
it just looks for that name in the appropriate paths (RPATH
directories specified by the executable, systems defaults,
LD_LIBRARY_PATH)
And to speed up that search the system keeps a cache of known
libraries and their locations, see 'man ldconfig'

> Also, if `libbar.so` doesn't have an soname, what exactly did you mean
> when you wrote that the binary product will include the "full path"?

Exactly what you observed in your first email:
This line results in a binary which when analyzed with `ldd(1)`, shows
a dependency on `/foo/bar.so`.

If you want the executable to have a dependency on "bar.so" then you
need to give it a soname of "bar.so" otherwise the dependency is on
the filename of the library the executable is linked to, in your case
that's /foo/bar.so

You should be able to test all this very simply with some simple
example code and convince yourself of how it works.