Re: Setting macOS shared library versioning information with scons

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".

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. 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.



On Wed, Oct 10, 2018 at 5:02 PM Bill Deegan <[email protected]>
wrote:

> SO a
> SOLIBVERSION=2.3
> SOLIBCOMPATVERSION=  defaults to say 2.0 in this case, but user can set?
>
> -Bill
>
> On Wed, Oct 10, 2018 at 3:01 PM Andrew C. Morrow <
> [email protected]> wrote:
>
>>
>> I don't think you can draw that conclusion. It depends on the semantics
>> of the versioning scheme for the library and any broader piece of software
>> of which the library may be a subcomponent. In particular, you could have a
>> project that has reached version 8.1.3. Within it, you have a library
>> libfoo that is on its second ABI revision. In the change from 8.1.2 to
>> 8.1.3 a new function was for the first time added (not a breaking change)
>> to the v2 ABI of libfoo. I'd expect the following on linux and darwin,
>> respectively:
>>
>>
>> SHLIBVERSION=8.1.3
>> SONAME=libfoo.so.2
>> libfoo.so -> libfoo.so.2 -> libfoo.so.8.1.3
>>
>> SHLIBVERSION=8.1.3
>> SONAME=libfoo.2.dylib
>> -current_version=1.1 -compatibility_version=1.0
>> libfoo.dylib -> libfoo.2.dylib -> libfoo.8.1.3.dylib
>>
>> The important thing is that the -current_version and
>> -compatibility_version are meant to track only minor ABI changes, not
>> major. Major's go in the SONAME/install_name. I was also surprised to note
>> that the InstallVersionedLib stuff simply seems not to work at all on
>> darwin platforms?
>>
>> For a simpler package, with just one library, where the major version
>> *is* the ABI and we are following semver only for the ABI, then sure, maybe
>> it is reasonable to decompose SHLIBVERSION=1.2.3 as using 1 for SONAME, and
>> then 2.3 as -current-version and 2.0 as -compatibility_version.
>>
>> But the point is I don't think you can assume either way.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jul 16, 2018 at 10:41 PM Bill Deegan <[email protected]>
>> wrote:
>>
>>> I added onto the macports bug.
>>>
>>> Here's my question:
>>>
>>> Given SHLIBVERSION = 1.2.3
>>>
>>> What would you expect/want the arguments to -current_version and
>>> -compatibility_version to be?
>>>
>>> Both to SHLIBVERSION (1.2.3) or compatibility_version to 1.2?
>>>
>>> (SCons developer here)
>>>
>>>
>>> On Wed, May 9, 2018 at 1:30 PM, Ryan Schmidt <[email protected]>
>>> wrote:
>>>
>>>> On May 8, 2018, at 13:02, Bill Deegan wrote:
>>>>
>>>> > On Tue, May 8, 2018 at 12:40 PM, Ryan Schmidt wrote:
>>>> >
>>>> >> I'm a developer with the MacPorts package management system.
>>>> >>
>>>> >> We noticed that after updating our scons port to 2.4.1, serf's
>>>> shared library was built incorrectly, in that its current version and
>>>> compatibility version were no longer being set. Here is our bug report
>>>> about this:
>>>> >>
>>>> >> https://trac.macports.org/ticket/50854
>>>> >>
>>>> >> It seems that scons's shared library generation code was refactored
>>>> in 2.4.1, and in the process, the code that sets the -current_version and
>>>> -compatibility_version flags was removed. Was this regression intentional,
>>>> and if so, how are projects that use scons to build shared libraries on
>>>> macOS now supposed to set library version information? Should they manually
>>>> specify -current_version and -compatibility_version?
>>>> >>
>>>> >> I realize scons 2.4.1 was released 2.5 years ago, but the problem
>>>> remains in scons 3.0.1. The developers of serf are preparing to release
>>>> serf 1.4.0, and I'm trying to help them ensure that they finally fix the
>>>> shared library versioning issue on their end, hopefully in a way that's
>>>> compatible with both current and future versions of scons.
>>>> >
>>>> > Looks like (as you're pointing out), the updates to support shared
>>>> library versioning on other platforms broke mac?
>>>> >
>>>> > Can you point me to the serf logic where they build the shared
>>>> library using SCons?
>>>> > (So I can see how they're calling SharedLibrary(),etc.)
>>>> >
>>>> > Certainly that's an indicator that however it was being used our
>>>> tests weren't covering that usage to ensure it didn't get broken.
>>>>
>>>> Here's serf's SConstruct:
>>>>
>>>> https://svn.apache.org/repos/asf/serf/trunk/SConstruct
>>>>
>>>> It is doing this:
>>>>
>>>>
>>>> # This version string is used in the dynamic library name, and for Mac
>>>> OS X also
>>>> # for the compatibility_version option in the .dylib.
>>>> soversion = '%d.%d.%d' % (MAJOR, MINOR, 0)
>>>> libversion = '%d.%d.%d' % (MAJOR, MINOR, PATCH)
>>>> if sys.platform != 'sunos5':
>>>>   env['SHLIBVERSION'] = soversion
>>>>
>>>>
>>>> install_shared = env.InstallVersionedLib(libdir, lib_shared)
>>>>
>>>>
>>>> The CHANGES.txt entry for scons 2.4.1 states:
>>>>
>>>> - InstallVersionedLib() doesn't use SHLIBVERSION anymore.
>>>>
>>>> So the change sounds deliberate. But it doesn't explain why.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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
>

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