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