How to check for backward compatibility of API and ABI of library.
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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 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
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
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
Does sbbdep process packages other than SBo Packages ?
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 :-)
Quote:
Originally Posted by kjhambrick
Does sbbdep solve Didier Spaier's knotty problem of library version compatibility ?
no, since this is a different problem and requires something total different, old lib - new lib and check if they are ABI compatible.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.