glib2 current/compatibility version

[Lawrence Velázquez]

Please read Apple's documentation on dylibs before spilling more ink on
this subject; there are several lengthy sections on versioning.

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries


On Jun 3, 2015, at 8:40 PM, René J.V. Bertin <rjvbertin at gmail.com>
wrote:

> I just stumbled across the fact that the glib2 port apparently bumps
> both the compatibility and the current version info stored inside its
> library, without change in the versioning of the library file names.

Nothing wrong with that. The major version encoded in the library name
is technically and semantically independent from the compatibility and
minor versions stored in the library itself.


> The latter (as well as the actual version string) suggest an unchanged
> ABI, which is contradicted and rendered moot by the changes
> compatibility version.

No, that is not what compatibility version means. And an unchanged major
version doesn't preclude *new* symbols.

Josh summed up the rules a month ago.

> From: Joshua Root <jmr at macports.org>
> Subject: Re: Proper library version numbering
> Date: May 2, 2015 at 8:09:27 PM EDT
> To: Ryan Schmidt <ryandesign at macports.org>
> Cc: Lawrence Velázquez <larryv at macports.org>, MacPorts Development
>     <macports-dev at lists.macosforge.org>
> 
> tl;dr version:
> 
> Increase current_version when the library changes in any way.
> 
> Increase compatibility_version when new symbols are added.
> 
> Increase the major version (AKA "soname") when any symbols are removed
> or have their semantics changed.


> glib2 2.42.1 => compatibility version 4201.0.0, current version 4201.1.0
> glib2 2.44.1 => compatibility version 4401.0.0, current version 4401.1.0
> 
> Are there grounds for this

That depends on whether 2.44.1 introduced new API over 2.42.1. I don't
follow glib development, so I don't know whether the bump in
compatibility version was warranted.


> will an application linked against glib2 2.44.1 not load or function
> on a system with glib2 2.42.1 installed (say on Linux where the
> dynamic loader won't complain about "Incompatible library version:
> vala requires version 4401.0.0 or later, but libgmodule-2.0.0.dylib
> provides version 4201.0.0")


On Darwin, that application will not load the 2.42.1 library, no.

I don't know whether Linux dynamic loading involves the concepts we're
discussing, beyond the major library number encoded in the file name.


> Increasing the internal versions without reason makes it impossible
> (or at least very impractical) to reactivate an older version of
> a dependent port.

You are mistaken. There should be no problem reactivating older
*dependents*, but there might be problems reactivating older
*dependencies*.

Assuming the library's development isn't a disaster, a client linked
against libfoo.A.dylib should be able to load any newer version of
libfoo.A.dylib. However, it doesn't work in the other direction: The
client can only load older versions that are newer than the
compatibility version dictated at link time.


> IMHO, glib2's build system should be corrected so that it keeps the
> library internal compatibility version string constant until there is
> an actual ABI discontinuity.

I don't know what you mean by "discontinuity". The compatibility version
should be increased whenever new non-weakly-linked symbols are added to
the library. No exceptions.

Of course, if there isn't a reason to change the compatibility version,
they shouldn't be doing so, if only because it's misleading. But that
doesn't concern us very much, since we don't support situations in which
libraries get older with respect to what their clients linked to.


vq