soname: libobs.so.30 vs libobs.so.0

Operating System Info

Debian

OBS Studio Version

32.0.4

Expected Behavior

I expect libobs to provide a stable API/ABI, and use proper soversioning for API/ABI breaks.

For the Debian-official packages of obs-studio I would like to be able to express proper versioned dependencies, as this is the only way to get smooth distribution upgrades.

Current Behavior

OBS version	libobs	symlink	dev library
32.0.4	libobs.so.30	libobs.so.0 -> libobs.so.30	libobs.so -> libobs.so.30
30.2.3	libobs.so	libobs.so.0 -> libobs.so.30	libobs.so -> libobs.so.0

resp.:

$ find obs-studio-3* -name "libobs.so*" -ls
   276127   1160 -rw-r--r--   1 user user  1185280 Dec 10  2023 obs-studio-30.0.2/usr/local/lib/libobs.so.30
   276126      0 lrwxrwxrwx   1 user user       12 Dec 10  2023 obs-studio-30.0.2/usr/local/lib/libobs.so.0 -> libobs.so.30
   276125      0 lrwxrwxrwx   1 user user       11 Dec 10  2023 obs-studio-30.0.2/usr/local/lib/libobs.so -> libobs.so.0
   274054   1132 -rw-r--r--   1 user user  1155528 Dec 13 21:59 obs-studio-32.0.4/usr/local/lib/x86_64-linux-gnu/libobs.so.30
   274053      0 lrwxrwxrwx   1 user user       12 Dec 13 21:59 obs-studio-32.0.4/usr/local/lib/x86_64-linux-gnu/libobs.so.0 -> libobs.so.30
   274052      0 lrwxrwxrwx   1 user user       12 Dec 13 21:59 obs-studio-32.0.4/usr/local/lib/x86_64-linux-gnu/libobs.so -> libobs.so.30

a 3rd-party plugin (I tested with obs-color-monitor, but I'm sure the same applies to others as well), will behave slightly different depending on whether it was linked against obs-studio-32.0.4 or obs-studio-30.2.3:

compiled against 32.0.4, I get:

$ readelf -d color-monitor.so  | grep NEEDED | grep libobs
 0x0000000000000001 (NEEDED)             Shared library: [libobs-frontend-api.so.30]
 0x0000000000000001 (NEEDED)             Shared library: [libobs.so.30]

whereas compiled against 30.2.3, I get

$ readelf -d color-monitor.so  | grep NEEDED | grep libobs
 0x0000000000000001 (NEEDED)             Shared library: [libobs-frontend-api.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libobs.so.0]

what is the reasoning for this weird behaviour?

now, because libobs.so.0 is a symlink to libobs.so.30 (in both cases), it might appear that libobs from 32.0.4 is a drop-in-replacement for libobs from 30.2.3.
only... it is not. symbols have been removed from libobs between 30.2.3 and 32.0.4 (e.g. obs_frontend_get_app_config).
the net outcome of this is, that if I compile obs-color-monitor against OBS-30.2.3, I get a binary that is not usable with OBS-32.0.4.

Anything else we should know?

now the problem of incompatible libraries is not anything new, so people came up with solutions for this decades ago: soname versioning.

would it be possible to provide a clear and consistent soname scheme for the libobs* libraries, so it's easier to detect incompatibilities and get inter-package dependencies right?

that is:

• drop the libobs.so.0 symlink; it doesn't serve any good.
• bump the soversion whenever there's a breaking change in the ABI (usually this means: whenever a symbol is removed from the library)
• maybe add a Provides: libobs<soname> (e.g. Provides: libobs30) to your Debian/Ubuntu package, so plugins that want to provide their own debs can add proper dependencies.

Start by inspecting how the libobs and libobs-frontend-api shared libraries receive their SONAMEs and how Debian packages expose them. Compare the readelf NEEDED output shown for OBS 30.2.3 and 32.0.4; done means ABI-breaking changes produce consistent dependency-detectable library versions without misleading compatibility symlinks.