RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Sune Vuorela]

On 2009-04-24, Aaron J. Seigo <aseigo at kde.org> wrote:
> --nextPart3268596.lq2LrkQFmB
> Content-Type: text/plain;
>   charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> On Thursday 23 April 2009, Sune Vuorela wrote:
>> On 2009-04-24, Aaron J. Seigo <aseigo at kde.org> wrote:
>> > 2) please don't use libknotification-1.so, use libknotification.so.1
>>
>> Yes. this. and proper change .so.1 to .so.2 (and the SONAME as seen by
>> the linker & friends)
>
> i'm fine with that as long as you can guarantee me that nobody will link=20
> against libknotification.so, and thereby cause havoc when BC is broken betw=
> een=20
> minor releases of kde.
>
> `ls -l /usr/lib/*[1-9].so` is pretty enlightening as well
>
> so, what's the benefit you see so so.1, so.2? i just see a potential landmi=
> ne=20
> due to symlinking to .so and app devs making the mistake of linking to the=
>=20
> wrong thing ...

(Disclaimer: I don't know how much of the following applies to
non-linux)

Most of the symlink chain .so > .so.X > .so.X.Y.Z is for convenience.

The important thing is the SONAME of the library and the NEEDED entries
of what uses it.

$ objdump -x /usr/lib/libkdecore.so.5 | grep SONAME
  SONAME               libkdecore.so.5
$ ls /usr/lib/libkdecore.so*
/usr/lib/libkdecore.so  /usr/lib/libkdecore.so.4
/usr/lib/libkdecore.so.4.2.0  /usr/lib/libkdecore.so.5
/usr/lib/libkdecore.so.5.2.0

When building, the SONAME of the library you link against gets put into
your binary as a NEEDED entry.

[foo.cpp is just a main method]
$ g++ -o foo foo.cpp /usr/lib/libkdecore.so
$ objdump -x foo | grep NEEDED
  NEEDED               libkdecore.so.5
  [more libs]
$ g++ -o foo foo.cpp /usr/lib/libkdecore.so.5
$ objdump -x foo | grep NEEDED
  NEEDED               libkdecore.so.5

$ g++ -o foo foo.cpp /usr/lib/libkdecore.so.4
$ objdump -x foo | grep NEEDED
  NEEDED               libkdecore.so.4

and at runtime, the linker looks up the files matching the NEEDED
entries in the RPATH of the binary, in LD_LIBRARY_PATH and in the
default paths for ld.

It doesn't matter what you link to. the unversioned symlink is just for
convenince to make 
$ g++ -o foo foo.cpp -lkdecore


This is only going to break if users symlink the .so.X to .so.Y, and
well.


The only issue is if libfoo uses libbar.so.X and application uses libfoo
and libbar.so.Y, but you have the same issues if you use different
namings. (Several of the same symbols loaded into the same app, things
gets confused. Versioned symbols is the fix here, but that's for another
day to discuss)

The main benefit of .so.1 .so.2 ... is that "this is how it is done in
general, so people know it". When there is well established practices
for handling abi breakages, why not use them?

(And another nice thing is that the debian autodependency calculation
tools handles proper versioned libraries much better than unversioned
ones)

/Sune