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 <[email protected]> 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 <[email protected]> > Subject: Re: Proper library version numbering > Date: May 2, 2015 at 8:09:27 PM EDT > To: Ryan Schmidt <[email protected]> > Cc: Lawrence Velázquez <[email protected]>, MacPorts Development > <[email protected]> > > 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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
