Re: Setting macOS shared library versioning information with scons

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