You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Ryan Schmidt <se...@ryandesign.com> on 2018/05/08 16:52:20 UTC
Re: Shared library version on macOS
On May 8, 2018, at 10:34, Branko Čibej wrote:
> On 08.05.2018 17:18, Branko Čibej wrote:
>> On 07.05.2018 15:11, Ryan Schmidt wrote:
>>> On May 3, 2018, at 15:11, Branko Čibej wrote:
>>>
>>>> I think there are more than enough improvements on trunk[1] to warrant a
>>>> new release; whether that's called 1.4.0 or 2.0 (which is the current
>>>> trunk version) doesn't really matter; but more than a year and a half
>>>> since the last release, it really is time for a new one.
>>>>
>>>> I'd be happy to do the RM tasks if necessary.
>>>>
>>>> Thoughts?
>>>>
>>>> -- Brane
>>>>
>>>> [1] I'm aware of:
>>>>
>>>> * HTTP/2
>>>> * OCSP client request and response handling
>>>> * Brotli compression
>>>> * Better support for building with OpenSSL 1.0.x/1.1.x and LibreSSL
>>> It would be great if libserf could get its library versioning information back on macOS with scons 2.4.1 and later. It's been missing for over 2 years already.
>>>
>>> http://mail-archives.apache.org/mod_mbox/serf-dev/201709.mbox/%3cB86D4FE3-0129-4AA7-A03C-A478AF41E4AF@ryandesign.com%3e
>> I appreciate your fiery passionate hatred for scons, but someone has to
>> step up with a fix to our build scripts or cross-platform replacement
>> (which these days would mean cmake, which I have a fiery passionate
>> hatred for ... go figure).
Oh yes, cmake is terrible too, though because it's more popular than scons it might be slightly less terrible. All build systems are terrible...
> Does this fix the problem for you? It looks like a bit of a horrible
> hack to me, but appears to work:
>
>
> Index: SConstruct
> ===================================================================
> --- SConstruct (revision 1830991)
> +++ SConstruct (working copy)
> @@ -236,8 +236,13 @@ incdir = '$PREFIX/include/serf-$MAJOR'
> # Unfortunately we can't set the .dylib compatibility_version option separately
> # from current_version, so don't use the PATCH level to avoid that build and
> # runtime patch levels have to be identical.
> +current_version = '%d.%d.%d' % (MAJOR, MINOR, PATCH)
> +compat_version = '%d.%d.%d' % (MAJOR, MINOR, 0)
> if sys.platform != 'sunos5':
> - env['SHLIBVERSION'] = '%d.%d.%d' % (MAJOR, MINOR, 0)
> + env['SHLIBVERSION'] = compat_version
> +if sys.platform == 'darwin':
> + env.Append(LINKFLAGS=['-Wl,-current_version,' + current_version,
> + '-Wl,-compatibility_version,' + compat_version])
>
> LIBNAME = '%sserf-%d' % (env['LIBPREFIX'], MAJOR)
> if sys.platform == 'win32':
That does work for me, thanks.
When the scons shared library generation code was refactored in scons 2.4.1, the code that sets the -current_version and -compatibility_version flags disappeared. I don't know why. Maybe every project that uses scons to build a shared library on macOS is now expected to pass those flags manually, just as projects already had to pass the -install_name flag on macOS. Serf used to set -current_version and -compatibility_version years ago, until that was removed in r1699700.
I looked through the scons-users mailing list archives from the release of 2.4.1 to present and didn't see a discussion of the issue. I didn't see any issues on their GitHub project about it. I've now asked about it on their mailing list. My post hasn't gone through yet but it should appear here eventually:
https://pairlist4.pair.net/pipermail/scons-users/2018-May/thread.html
Re: Shared library version on macOS
Posted by Branko Čibej <br...@apache.org>.
On 08.05.2018 19:24, Branko Čibej wrote:
> On 08.05.2018 18:52, Ryan Schmidt wrote:
>> On May 8, 2018, at 10:34, Branko Čibej wrote:
>>> On 08.05.2018 17:18, Branko Čibej wrote:
>>>> On 07.05.2018 15:11, Ryan Schmidt wrote:
>>>>> On May 3, 2018, at 15:11, Branko Čibej wrote:
>>>>>
>>>>>> I think there are more than enough improvements on trunk[1] to warrant a
>>>>>> new release; whether that's called 1.4.0 or 2.0 (which is the current
>>>>>> trunk version) doesn't really matter; but more than a year and a half
>>>>>> since the last release, it really is time for a new one.
>>>>>>
>>>>>> I'd be happy to do the RM tasks if necessary.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> -- Brane
>>>>>>
>>>>>> [1] I'm aware of:
>>>>>>
>>>>>> * HTTP/2
>>>>>> * OCSP client request and response handling
>>>>>> * Brotli compression
>>>>>> * Better support for building with OpenSSL 1.0.x/1.1.x and LibreSSL
>>>>> It would be great if libserf could get its library versioning information back on macOS with scons 2.4.1 and later. It's been missing for over 2 years already.
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/serf-dev/201709.mbox/%3cB86D4FE3-0129-4AA7-A03C-A478AF41E4AF@ryandesign.com%3e
>>>> I appreciate your fiery passionate hatred for scons, but someone has to
>>>> step up with a fix to our build scripts or cross-platform replacement
>>>> (which these days would mean cmake, which I have a fiery passionate
>>>> hatred for ... go figure).
>> Oh yes, cmake is terrible too, though because it's more popular than scons it might be slightly less terrible. All build systems are terrible...
>>
>>
>>> Does this fix the problem for you? It looks like a bit of a horrible
>>> hack to me, but appears to work:
>>>
>>>
>>> Index: SConstruct
>>> ===================================================================
>>> --- SConstruct (revision 1830991)
>>> +++ SConstruct (working copy)
>>> @@ -236,8 +236,13 @@ incdir = '$PREFIX/include/serf-$MAJOR'
>>> # Unfortunately we can't set the .dylib compatibility_version option separately
>>> # from current_version, so don't use the PATCH level to avoid that build and
>>> # runtime patch levels have to be identical.
>>> +current_version = '%d.%d.%d' % (MAJOR, MINOR, PATCH)
>>> +compat_version = '%d.%d.%d' % (MAJOR, MINOR, 0)
>>> if sys.platform != 'sunos5':
>>> - env['SHLIBVERSION'] = '%d.%d.%d' % (MAJOR, MINOR, 0)
>>> + env['SHLIBVERSION'] = compat_version
>>> +if sys.platform == 'darwin':
>>> + env.Append(LINKFLAGS=['-Wl,-current_version,' + current_version,
>>> + '-Wl,-compatibility_version,' + compat_version])
>>>
>>> LIBNAME = '%sserf-%d' % (env['LIBPREFIX'], MAJOR)
>>> if sys.platform == 'win32':
>> That does work for me, thanks.
>>
>> When the scons shared library generation code was refactored in scons 2.4.1, the code that sets the -current_version and -compatibility_version flags disappeared. I don't know why. Maybe every project that uses scons to build a shared library on macOS is now expected to pass those flags manually, just as projects already had to pass the -install_name flag on macOS. Serf used to set -current_version and -compatibility_version years ago, until that was removed in r1699700.
>>
>> I looked through the scons-users mailing list archives from the release of 2.4.1 to present and didn't see a discussion of the issue. I didn't see any issues on their GitHub project about it. I've now asked about it on their mailing list. My post hasn't gone through yet but it should appear here eventually:
>>
>> https://pairlist4.pair.net/pipermail/scons-users/2018-May/thread.html
>
> I see your mail in the archive now. Thanks for following up.
In the meantime, I committed a slightly modified version of my patch in
r1831201. Since I don't think we'll bother making another 1.3.x release,
there's probably no reason to backport the change.
-- Brane
Re: Shared library version on macOS
Posted by Branko Čibej <br...@apache.org>.
On 08.05.2018 18:52, Ryan Schmidt wrote:
> On May 8, 2018, at 10:34, Branko Čibej wrote:
>> On 08.05.2018 17:18, Branko Čibej wrote:
>>> On 07.05.2018 15:11, Ryan Schmidt wrote:
>>>> On May 3, 2018, at 15:11, Branko Čibej wrote:
>>>>
>>>>> I think there are more than enough improvements on trunk[1] to warrant a
>>>>> new release; whether that's called 1.4.0 or 2.0 (which is the current
>>>>> trunk version) doesn't really matter; but more than a year and a half
>>>>> since the last release, it really is time for a new one.
>>>>>
>>>>> I'd be happy to do the RM tasks if necessary.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> -- Brane
>>>>>
>>>>> [1] I'm aware of:
>>>>>
>>>>> * HTTP/2
>>>>> * OCSP client request and response handling
>>>>> * Brotli compression
>>>>> * Better support for building with OpenSSL 1.0.x/1.1.x and LibreSSL
>>>> It would be great if libserf could get its library versioning information back on macOS with scons 2.4.1 and later. It's been missing for over 2 years already.
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/serf-dev/201709.mbox/%3cB86D4FE3-0129-4AA7-A03C-A478AF41E4AF@ryandesign.com%3e
>>> I appreciate your fiery passionate hatred for scons, but someone has to
>>> step up with a fix to our build scripts or cross-platform replacement
>>> (which these days would mean cmake, which I have a fiery passionate
>>> hatred for ... go figure).
> Oh yes, cmake is terrible too, though because it's more popular than scons it might be slightly less terrible. All build systems are terrible...
>
>
>> Does this fix the problem for you? It looks like a bit of a horrible
>> hack to me, but appears to work:
>>
>>
>> Index: SConstruct
>> ===================================================================
>> --- SConstruct (revision 1830991)
>> +++ SConstruct (working copy)
>> @@ -236,8 +236,13 @@ incdir = '$PREFIX/include/serf-$MAJOR'
>> # Unfortunately we can't set the .dylib compatibility_version option separately
>> # from current_version, so don't use the PATCH level to avoid that build and
>> # runtime patch levels have to be identical.
>> +current_version = '%d.%d.%d' % (MAJOR, MINOR, PATCH)
>> +compat_version = '%d.%d.%d' % (MAJOR, MINOR, 0)
>> if sys.platform != 'sunos5':
>> - env['SHLIBVERSION'] = '%d.%d.%d' % (MAJOR, MINOR, 0)
>> + env['SHLIBVERSION'] = compat_version
>> +if sys.platform == 'darwin':
>> + env.Append(LINKFLAGS=['-Wl,-current_version,' + current_version,
>> + '-Wl,-compatibility_version,' + compat_version])
>>
>> LIBNAME = '%sserf-%d' % (env['LIBPREFIX'], MAJOR)
>> if sys.platform == 'win32':
> That does work for me, thanks.
>
> When the scons shared library generation code was refactored in scons 2.4.1, the code that sets the -current_version and -compatibility_version flags disappeared. I don't know why. Maybe every project that uses scons to build a shared library on macOS is now expected to pass those flags manually, just as projects already had to pass the -install_name flag on macOS. Serf used to set -current_version and -compatibility_version years ago, until that was removed in r1699700.
>
> I looked through the scons-users mailing list archives from the release of 2.4.1 to present and didn't see a discussion of the issue. I didn't see any issues on their GitHub project about it. I've now asked about it on their mailing list. My post hasn't gone through yet but it should appear here eventually:
>
> https://pairlist4.pair.net/pipermail/scons-users/2018-May/thread.html
I see your mail in the archive now. Thanks for following up.
-- Brane