serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: Shared library version on macOS
Date Tue, 08 May 2018 17:24:10 GMT
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


Mime
View raw message