Re: Setting macOS shared library versioning information with scons

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