[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-audio-dev
Subject:    [LAD] library soname, was Re:  Rubber Band Library v3.0.0 released
From:       "Chris Cannam" <cannam () all-day-breakfast ! com>
Date:       2022-07-28 13:52:03
Message-ID: 8c5e4398-518e-4df6-a1ba-ada728425903 () www ! fastmail ! com
[Download RAW message or body]


On Fri, 15 Jul 2022, at 23:02, Robin Gareus wrote:
> Congrats on the release and thanks for the very informative blog post.

Thank you!

> https://hg.sr.ht/~breakfastquay/rubberband/browse/rubberband.pc.in?rev=v3.0.0
> 
> states Version: 1.8.2 (not 3.0.0).
> The ABI version of the shared object is 2.2.0
> 
> Is that expected?

Yes to both... I hope.

The version in the .pc file is written in at install time, although I guess it would be nice to have the \
right version in place in .pc.in in the first place (or to omit it until installation) as it does look \
kind of confusing.

The ABI has been at 2.something since version 1.2, which was the last release to break binary \
compatibility. This release bumped it from 2.1.7 to 2.2.0. A program dynamically linked against version \
1.2 will still run correctly against this new version.

But I find that after all these years I am still not totally clear on whether a *compatible* change to \
the ABI should cause a change to the soname, or only to the minor number. I thought I knew this, but I \
find now that sources contradict each other, and sometimes themselves, with great confidence - and it's \
been such a long time that I can no longer remember exactly why I formed my own view in the first place.

For example:

https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

section 3.1.1 "The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed \
by a period and a version number that is incremented whenever the interface changes". This implies that \
if you e.g. add a function, you should change the soname.

section 3.6 "When a new version of a library is binary-incompatible with the old one the soname needs to \
change... you can keep your Application Binary Interface (ABI) compatible if you avoid such changes. For \
example, you might want to add new functions but not delete the old ones". This implies that if you add a \
function, you need not change the soname.

I always took the view that if the library can be upgraded without breaking an application linked against \
the old version, it should have the same soname (i.e. first component of ABI version) because the \
alternative would be too annoying in practice. That seems consistent with many other libraries, anyway. \
But it does mean that library downgrades don't fail cleanly and I am definitely finding sources out there \
that suggest it isn't the right thing to do after all. Has consensus on this changed over the years \
perhaps?


Chris
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev


[prev in list] [next in list] [prev in thread] [next in thread]