soname change with every release (with 4.6.1 in a patch level release)

[dvzrv]

The current setup introduces a shared object name change on a patch level release, which leads to rebuilds of all dependants in a Linux distribution!

drwxr-xr-x root/root         0 2019-04-18 18:56 usr/lib/
-rw-r--r-- root/root    904296 2019-04-18 18:56 usr/lib/libstk-4.6.1.so
lrwxrwxrwx root/root         0 2019-04-18 18:56 usr/lib/libstk.so -> libstk-4.6.1.so

This is not what should happen on a patch level release, as it breaks the assumption of using semver, as specified in RFC 2119.
If the API has changed significantly, at least a version 4.7.0 or 5.0.0 should have been released instead of 4.6.1. If the API was not changed, a soname change is not required.

In a situation where an API change did not take place, the versioning of the shared object should be changed to e.g.:

libstk.so -> libstk.so.4
libstk.so.4 -> libstk-4.6.1.so

[dvzrv]

Hm, thinking of it, it should be rephrased to "soname change on every release", as that's actually the problem here.

[dvzrv]

To give a little background on how badly this scales: I have to rebuild csound, lmms, polyphone and sc3-plugins on every release of stk.

Given the fact, that this has already been noticed last year (#86) but without any comment, it really makes me wonder why this was not addressed earlier.

[radarsat1]

Sorry, STK doesn't use libtool and libstk doesn't have an soname separate from the library release version, we simply consider it unstable. (Though it relatively is not.)

I have to rebuild csound, lmms, polyphone and sc3-plugins on every release of stk.

Is that a lot, once a year or so? I have no idea.

It's not clear to me why you need to rebuild everything since none of these programs yet use the new features of this point release. There is a total of 1 small bug fix in FileLoop::getSize, but it is not critical.

it really makes me wonder why this was not addressed earlier.

Because nobody submitted a PR for, e.g. a complete CMake-based build system. In RtAudio and RtMidi we have accepted such community-maintained build systems due to popular demand, even though they add a burden to the maintainers, but the community desire for it seems overwhelming. We haven't yet done so in STK but feel free to continue the discussion. It is of course frustrating to simply hear a complaint of "why wasn't something done!" when it's been a year that anyone could have contributed it.

That said, as opposed to RtAudio and RtMidi, the aim of STK is to document implementations of physical audio models, not to provide a stable development platform for Linux distributions. If you wish to maintain an ABI model through your own patches or fork or whatnot you are absolutely free to do this yourself.

The current "bump ABI at each release" was implemented by a debian developer (0063a57), so you can take it up with @fsateler.

I'll close this issue soon and you can open a PR instead if you wish to see changes. I should say that I think moving to your linking scheme is reasonable, or the more standard,

libstk.so -> libstk.so.4
libstk.so.4 -> libstk.so.4.6.1

and could be done with the current build system with very small changes.

but being sure of respecting semver is a burden for maintainers to be honest. This problem requires you recompile a few packages. It would have been much worse if the soname did not change despite the API/ABI changing -- semver mistakes are easy to make, particularly with C++ -- so it's better to be conservative. The current scheme is preferable from upstream point of view imho. Sorry if that adds a lot of work for you, though I am not clear on why rebuilding 4 packages is so difficult.

[fsateler]

Hi,

It seems to me the discussion about the technical bits is a bit superfluous at this point. ABI compatibility is difficult, in particular for C++ libraries. See the KDE guidelines if you want further information.

Incompatible ABI breaks lead to very subtle issues, which only appear later during runtime, and sometimes crash with very weird error messages. The difficulty of maintaining ABI compatibility, plus the severity and difficulty to debug of the issue caused by unexpected ABI compatibility breaks, means the library maintainers need to be very sure they want to commit to a stable ABI before actually committing to it.

As mentioned by Stephen, stk is not prepared to make such a commitment, and thus the sanest choice is to bump the SONAME version on each release, even if that means downstream distros like debian need to rebuild the reverse dependencies. Rebuild work can be automated, debug of subtle issues requires human time, which is a lot more difficult to come by.

I would strongly advise against pretending to have a stable ABI without a very serious commitment to maintaining that stability. Given the number of reverse dependencies, and the consequent ease of rebuilding them all, I think the STK project should stick to the unstable ABI and focus the scarce
resources they have on making the library better.

PS: semver has nothing to do with this issue, as semver is all about source compatibility, not binary compatibility.

@dvzrv said:

If the API was not changed, a soname change is not required.

This is incorrect. Adding fields to a class can break ABI (google/leveldb#536), changing the base class of a class also breaks ABI (thestk/rtaudio#17), and any number of changes that don't affect source compatibility will break binary compatibility.

[yurivict]

This is still outstanding.

Release 4.6.2 installs lib/libstk-4.6.2.so instead of lib/libstk.so.4.6.2.

[radarsat1]

Please see libtool docs on this: https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html

This says that it is better for STK to use the name-version.so scheme than the name.so.version scheme.

[yurivict]

libtool and gnu tools are obsolete. Both cmake and meson have no problem with libxx.so.version schema.