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. -- Brane
