Hendrik Boom <hendrik@???> writes:
> On Tue, Mar 01, 2016 at 11:41:46PM +0000, Rainer Weikusat wrote:
>> "T.J. Duchene" <tj@???> writes:
>> > On 2016-03-01 20:22, Rainer Weikusat wrote:
>>
>> And I disgree with your assessment of this being "a simplified"
>> description, instead of a fairly complicated and seriously deceptive
>> one.
>>
>> >> As single example: Applications aren't "compiled with" dynamic
>> >> libraries, they're combined with them at runtime which happens in the
>> >> same way regardless of the system they were compiled on.
>> >
>> > I am not trying to be rude or condescending, but if you prefer a more
>> > qualified answer to show that I know what I am talking about, then I
>> > must disagree with you. They are not "combined" with anything except
>> > a set of calls,
>>
>> Oh, they are. Try running pmap -d $$ in a shell to see this.
>
> As I once understood it, programs are linked to a stub. When the
> dynamic shared libraries are loaded, the stub s filled in with the
> addresses of the real library entry points.

As I already wrote twice, program's aren't "linked" to dynamic libraries
at all. At link time, the sonames of required dynamic libaries are
recorded in the binary,

[rw@doppelsaurus]~#readelf -d /bin/bash | grep -i needed
 0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

and at runtime, the runtime linker locates libraries 'claiming' the
needed sonames by searching through a certain set of directories (it's
actually using a cache but I am trying to simplify things). It maps the
corresponding shared objects into the address space of the process and
use the information in them to connect calls made in the applications
with actual routines available in these libraries based on searching for
'symbols' needed by an application in the set of 'symbols' provided by
the libraries, eg, the bash binary requests of of the following symbols
(that's a subset),

[rw@doppelsaurus]~#nm -D /bin/bash  | grep 'U dl'
                 U dlclose
                 U dlerror
                 U dlopen
                 U dlsym

by recording them as 'undefined' (U) and the libdl library provides
symbols with these names,

[rw@doppelsaurus]~#nm -D /usr/lib/x86_64-linux-gnu/libdl.so | grep 'T dl'
00000000000015e0 T dladdr
0000000000001600 T dladdr1
0000000000000ff0 T dlclose
00000000000013c0 T dlerror
0000000000001640 T dlinfo
0000000000001850 T dlmopen
0000000000000eb0 T dlopen
0000000000001030 T dlsym

The soname mechanism already provides an opportunity for having multiple
version of the same library installed as these cane use different
sonames but provide the same set of symbols. In addition to this, the
symbols themselves can be versioned which enables a single library to
provide different versions of a function with the same name, eg

[rw@doppelsaurus]~#objdump -T  /lib/x86_64-linux-gnu/libc.so.6 | grep pthread_cond_signal
00000000000eaac0 g    DF .text  0000000000000026  GLIBC_2.3.2 pthread_cond_signal
0000000000115890 g    DF .text  0000000000000026 (GLIBC_2.2.5) pthread_cond_signal

In case you really care about the technical details, a good description
is available here:

https://www.akkadia.org/drepper/dsohowto.pdf