GNOME Bugzilla – Bug 586804
libtool version flags mis-set for new public functions
Last modified: 2018-05-22 12:54:40 UTC
Going from libgsf-1.14.14 to 1.14.15, some new symbols were added to the public API of the libgsf shared library and published in the public gsf/*.h headers. However, the libtool versioning flags were not updated for this change. The API change itself is against libgsf's own stated compatibility rules. And by not setting flags properly, other libraries cannot use standard compatibility controls like dyld to make sure they are getting the minimum expected level of features. configure.in states: dnl Version info for libraries = CURRENT:REVISION:AGE dnl dnl Within each x.y.*, ABI is maintained backward and _forward_ compatible. dnl (As a consequence, no exported function may be added.) dnl So it's enough to have one interface number per each x.y.* branch. dnl dnl OTOH, we are not able to keep ABI strictly backward compatible throughout dnl the whole x.*.*. dnl The easiest way is to declare no ABI compatibility, ie. AGE is always 0. dnl m4_define([version_iface], m4_eval(100 * libgsf_version_major + libgsf_version_minor)) AC_SUBST([VERSION_INFO], [version_iface:libgsf_version_micro:0]) and of course the VERSION_INFO calculations don't include any way to adjust for a compatibility change that is self-prohibited.
The docs are wrong. I'll have to dig out why it says that. We add functions all the time. Is there an actual problem hidden here or did you just catch the discrepancy with the docs?
1. Install new ("with more public symbols") libgsf 2. Compile and link a program against libgsf 3. Downgrade libgsf to older ("without new symbols") libgsf or transfer program to machine with older libgsf 4. Run program Step 4 gives a dyld error about unresolved symbols, which is meaningless to anyone who doesn't know all the internals and change history of libgsf. If libgf adjusts its libtool flags in each version to reflect the API/ABI changes, then Step 4 gives a dyld error telling me that libgsf's interface version is too old (and even tells me the minimum one required, based on what libgsf interface version was present in Step 1). The -version-info really is public info about the version. If it didn't matter and nobody saw it or used the data, libtool wouldn't have such a convoluted set of flags for it:)
That was not what I meant to ask. I understand how it can be provoked to happen. I meant to ask if this has been observed or is expected to cause real trouble for a user who isn't actively trying to seek out the pain. I am very reluctant to touch configuration code that I cannot easily test because I don't have a closet full of different OSs and machines to test on. If the problem is just "Doctor, when I bang my head on the wall, it hurts!" I am not going to do it.
I'm one of the gnome managers for the Fink package-management system and I'm trying to make things as easy on us and our users (read "easier to diagnose problems and/or to set up packages to Do The Right Thing"). By using the proper flags, you simply declare the status of your library compatibility to others. That way I (packager) can know what versions to specify in my package descriptions to make sure users don't install a binary on an incompatible system and then force me to diagnose a non-self-explanatory error message. Libtool has very clear documentation on how to use the -version-info field specifically so authors *don't* have to test on every system. By using the flags per their docs, libtool handles everything as correct for the local platform and users and packagers all get whatever features and sanity-checks are available. I'm not sure what is gained by intentionally misusing your own build-system tools.
Here are the docs... http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html so it seems that setting AGE=0 is self-consistent with the self-imposed compatibility notes, but not required by anything in libtool (or gnome stable-branch ideas that I can find). CURRENT:VERSION:AGE just documents the state of (and changes to) the facts of the library.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgsf/issues/5.