Re: Setting macOS shared library versioning information with scons

From MacOS ld manpage:

Options when creating a dynamic library (dylib)
>      -install_name name
>                  Sets an internal "install path" (LC_ID_DYLIB) in a
> dynamic library. Any clients linked against the library
>                  will record that path as the way dyld should locate this
> library.  If this option is not specified, then
>                  the -o path will be used.  This option is also called
> -dylib_install_name for compatibility.
>
>      -compatibility_version number
>                  Specifies the compatibility version number of the
> library.  When a library is loaded by dyld, the compati-
>                  bility version is checked and if the program's version is
> greater that the library's version, it is an
>                  error.  The format of number is X[.Y[.Z]] where X must be
> a positive non-zero number less than or equal to
>                  65535, and .Y and .Z are optional and if present must be
> non-negative numbers less than or equal to 255.
>                  If the compatibility version number is not specified, it
> has a value of 0 and no checking is done when the
>                  library is used.  This option is also called
> -dylib_compatibility_version for compatibility.
>
>      -current_version number
>                  Specifies the current version number of the library. The
> current version of the library can be obtained
>                  programmatically by the user of the library so it can
> determine exactly which version of the library it is
>                  using.  The format of number is X[.Y[.Z]] where X must be
> a positive non-zero number less than or equal to
>                  65535, and .Y and .Z are optional and if present must be
> non-negative numbers less than or equal to 255.
>                  If the version number is not specified, it has a value of
> 0.  This option is also called -dylib_cur-
>                  rent_version for compatibility.
>
...

    -rpath path
>                  Add path to the runpath search path list for image being
> created.  At runtime, dyld uses the runpath when
>                  searching for dylibs whose load path begins with @rpath/.
>


So it looks like.
1 === 1.0 === 1.0.0?

Also sounds like it might be good to check the legality of the version
strings [1-65535].[0-255].[0-255] being the only legal version strings?

On Fri, Oct 12, 2018 at 1:30 AM Ryan Schmidt <[email protected]> wrote:

>
>
> 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 ha
>  s 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.
>
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users