[Scons-users] Setting macOS shared library versioning information with scons

[Ryan Schmidt]

On Oct 11, 2018, at 16:54, Andrew C. Morrow wrote:

> I think SOLIBVERSION=x.y.z should imply SOLIBCURRENTVERSION=y.z and SOLIBCOMPATVERSION=y.0, with options to override. The 'x' part of the version should be in the dylib filename and install_name. The current_version and compatibility_version appear to be "minor ABI".

Yes, current_version and compatibility_version are minor versions, install_name and file name contain the major version. All minor versions are converted to a three-number format (so e.g. 1 and 1.0 are converted to 1.0.0).

> I think SOLIBVERSION=x.y should imply SOLIBCURRENTVERSION=y and SOLIBCOMPATVERSION=y, with options to override? Not sure there.
> 
> One trouble with that: values of zero appear to mean "ignore" in this scheme.

Zero means ignore to whom? scons?

> Which is awkward if your SOLIBVERSION is 2.0.0, for instance. Not sure what to do there, as doing (y+1) (z+1) feels wrong.

Something to bear in mind maybe: The linker in old macOS versions (maybe 10.4 and earlier?) doesn't allow the current minor version or compatibility minor version to be 0. We may not care so much about macOS versions that old anymore, but libtool's handling of macOS dylibs was designed when that was still relevant, so when translating a libtool library's -version-info into macOS dylib version information, it ensures that the current and compatibility minor versions start at 1. This means that for libtool-made libraries these version numbers are 1 higher on macOS than they are on other operating systems that don't have that restriction. This causes problems virtually every time a developer switches their project from autotools to another build system like cmake that doesn't implement that same rule, because the developer inevitably makes the change while on an OS other than macOS, everything looks fine on that other OS, and they release a new version of their project which on macOS has library current and compatibility minor versions that are 1 less than they were on the previous version of their software, which makes them incompatible with any software that's linked with that library until that software is rebuilt. It feels like I encounter this problem all the time in MacPorts as we update libraries.

So what I'm saying is that using y+1 might not be such a bad defalt. But also that giving the developer the opportunity to override the defaults is a good idea too, in case they have an existing library with an existing versioning scheme that they need to match.