How to check for backward compatibility of API and ABI of library.
 

Hello,

I sometimes hesitate to upgrade a software for myself or for Slint, if its requirements have changed.

For instance upgrading from MATE 1.18 to MATE 1.20 requires GTK 3.22 and GLib 2.50 or newer, but Slackware 14.2 (and Slint 14.2) ship GTK 3.18.9 and GLib2-2.46.

I have found this website: https://abi-laboratory.pro/ that seems helpful.

Keeping the examples above, for GTK looking at this page I see that changes introduced in version 3.20.0 could be worrisome. It appears from here that there could be issues with removal of symbols in libgdk3, detailed in this page, which also mentions size changes of a type and a field.

A similar check for Glib highlights possible issues due to changes introduced in versions 2.47.2, 2.48.1, 2.50 and 2.52.0.

This leads to these questions:

• Is there a simple way to automatize checking of the installed binaries for usage of removed symbols, like running ldd or readelf?
• Is there a way to check the possible effects of size changes in installed software?
• If you have used https://abi-laboratory.pro/ what do you think of its reliability?
• Are there other (and better) tools and methods to assess the possible issues when upgrading a library.

I will be grateful for answers, advises and pointers coming from anyone and especially Pat and Slackware contributors.

if unsure, rebuild,
for Mate, if it says 3.20.0, and you use it with a lower version, rebuild to see what's missing. The version check for GTK lib is just something in the makefile / configure files, os it should be possible to fix.
if it's not compiling, you know, if it's compiling, use this build.
even if just minor changes, and the description is 'in a backward compatible manner', if the developers are not religious with compatibility, like Qt is, going down from minimum requirements is a good way to get in troubles.

the abi checker report you linked is useful, and the report says it, GDKEvent and scroll event have different binary size, so this is definitely a problem.
But I wonder if in this case the versioning of libgdk is as it should be ... maybe they are not that religious than others with there ABI compatibility

That's why i don't promote 3.20 to 14.2 supported releases since we all agreed that 3.20 is for newer GTK+3. It has been discussed by the upstream developers along with packagers. Slackware 14.2 has enjoyed several MATE releases and it's time for next Slackware to get the latest release of MATE :)

I do know this:

If you upgrade FFMPEG, you generally need to rebuild everything that depends on it.

this topic, btw, descripse the problem why I created sbbdep and why it has a --whoneeds option, to know what should (maybe) be rebuilded in case of an library update

sbbdep, a great tool indeed, use it a lot. :hattip:

Yes, thumbs up for sbbdep.

Does sbbdep process packages other than SBo Packages ?

In addition to sbbdep, if what you need is an in-order list of prerequisites suitable for shell scripting, chris.willing's SBo tool hoorex works for me.

But `hoorex -r -m ${SomeSBoPackage}` only resolves SBo Prerequisite Packages for SomeSBoPackage ( or `hoorex -m ${SomeSBoPackage}` finds the inverse == what SBo Packages depend on SomeSBoPackage ? )...

I don't know of any tool that can check the required version of each Prerequisite Library or Program file actually installed on the system.

The hoorex scrripts builds a Package Index from the REQUIRES= Variable in each SBo.info file so it can tell me what I need but not the version I need of each PreReq.

Does sbbdep solve Didier Spaier's knotty problem of library version compatibility ?

If so, that would certainly be worth modifying my build scripts :)

Thanks.

-- kjh

packages of any source, of course, and binary files that are, or not, part of any package

I had also the option to run it over a folder, so that yo can use it in a build script after the make install step for the DEST dir, to get the list of required libraries, but I haven't used this for years now, so I do not know if this option still exits/works :-)

no, since this is a different problem and requires something total different, old lib - new lib and check if they are ABI compatible.