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
