[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]