"T.J. Duchene" <tj@???> writes:
> On 2016-03-02 16:20, Rainer Weikusat wrote:
>> 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
>>
>
> Yes. All true.
>
> Libraries are installed and then linked using sonames that are
> symlinked rather than using the full soname. This is the proper way,
> so that you don't have to recompile and re-link every single time when
> a minor update is made. The full length sonames aren't used on a
> day-to-day basis. It is possible that a short form (symlinked)
> soname can get re-pointed from the distributions chosen version to
> whatever version was installed last. It's a human oversight, but it
> can cause problems with the linker.

You seem to be somewhat confused re: How this works and what it's
supposed to accomplish. The soname is a property of a particular library
file, eg, using libdb4 as example,

[rw@duesterwald]/usr/lib $readelf -d libdb-4.8.so | grep -i son
 0x000000000000000e (SONAME)             Library soname: [libdb-4.8.so]

and that's one the runtime linker cares about: When handling a NEEDED
entry in an ELF binary, it searches for a file with a matching SONAME
entry. The soname will usually be identical to/ reflected in the
filename but it doesn't have to be in this way. The prominent
counterexample would be the C libary whose soname has been fixed as
libc.so.6 regardless of the actual library version:

[rw@doppelsaurus]/lib#readelf -d /lib/x86_64-linux-gnu/libc-2.13.so | grep -i son
 0x000000000000000e (SONAME)             Library soname: [libc.so.6]
(example is for the actual C library file of a Wheezy install)

But that's just one side of the issue, the one concerned with locating a
library when starting an application. The other would be 'locating a
library when compiling/ linking one'. The information the
linker is supplied with will usually just be the proper name of the
library, the first part of the filename minus the leading lib,
eg, in order to link with the Berkeley DB library, one would usually
pass an argument of

-ldb

to the linker (driver). The linker will then search for a file named

lib<proper name>.so

in its library search path. This will usually be a symlink to most
recent installed version of a library, eg,

[rw@duesterwald]/usr/lib $ls -l libdb.so
lrwxrwxrwx 1 root root 12 Oct 9 2013 libdb.so -> libdb-4.8.so

and the soname in this file will then end up in a NEEDED section.

The idea behind this is that someone compiling an application will want
to associate it with the most recent version of "a certain libray", eg,
the Berkeley DB library, while an already compiled application should
continue to be runtime-linked with the library version it was compiled
with.

> That is what I was referring to when I made my earlier comment about
> the linker becoming "confused." It's not a correct answer in
> programming terms, but it is a very human one.

You've omitted a few steps on the path to the ultimate disaster: It will
usually also involve trying to "update the system" by copying random
stuff compiled from sources over some set of system-provided files
(especially effective for the C library as this will cause all running
applications to crash once they try to call into it and may prevent
starting new ones :-) and/ or trying to fixup the links manually based
on a half-cocked understanding of their purpose.

But handling this correctly is really not that difficult, even when
doing it manually: Provided a library file named in a suitable way has
been deposited in a library directory, eg, /usr/local/lib, invoking
ldconfig (as root, obviously) will take care of the rest, including
updating the runtime linker cache.