Hi Justin,
Ah, I hadn't checked the 1.3.x branch. Good to know that Python3 for
the build is supported there. :-). And I didn't see the things in
1.3.x/STATUS.
I can certainly sympathize with trying to find the right focus while
having (very) limited resources. So I think getting 1.4 out the door
is more important. And if it doesn't have those problems (and the
CMake build works on Windows), great!
For me personally the problem is already solved (I found the necessary
workarounds, and got SVN built with serf 1.3.9 combined with openssl
1.1.1f). If you (or anyone in dev@serf) feel like it, you might
perform some last fixes or document the kwown issues / workarounds in
README on the 1.3.x branch. That might still be a useful improvement,
even if you don't cut a new 1.3.10 anymore. But if you don't get
around to it, no problem ... 1.4.x is probably the way forward in any
case.
As soon as you cut a 1.4 release, with a CMake build that would work
on Windows (with VS 2019), I will certainly try it for my next SVN
build. I'm subscribed to this list now, so I should be able to see the
announcement :-).
Thanks for your efforts,
--
Johan
On Mon, Apr 20, 2020 at 1:34 PM Justin Erenkrantz <jus...@erenkrantz.com> wrote:
>
> Johan,
>
> Thanks for the note!
>
> The Python3 patches should already be in 1.3.x branch ready for our next
> release. We've also got 2 +1s in STATUS for VS 2017 support for 1.3.x, but
> I've yet to be able to confirm it for 2017 myself and also there's now 2019
> as well...so, I've held off merging that change. And, I haven't yet gotten
> as far as trying to compile with OpenSSL 1.1.x either on Windows; so, I
> expect if I got to that, your patch is very helpful for SCons.
>
> However, I posted a few weeks ago on-list and there wasn't a lot of interest
> in making a new 1.3.x release; so, I've been focusing on the 1.4.x branch
> which switches over to CMake as that seems to be where the world is going
> now. Most of the issues that we have right now seem to stem from Python and
> our creaky build system - not actual serf bugs. Though it is a bit of a slog
> for me to get CMake up, so I don't have a firm ETA on a release there.
>
> If we can muster two other interested folks for a 1.3.10 release, I think
> that I can shift gears a bit and focus on completing the 1.3.x stuff which
> should include most of the relevant build fixes for modern toolchains...but,
> it's probably not the right focus long-term as there's a bunch of cool
> features in 1.4.x that would love to see the light of day.
>
> Cheers. -- justin
>
> On Sun, Apr 19, 2020 at 9:47 AM Johan Corveleyn <jcor...@gmail.com> wrote:
>>
>> Hi serf devs,
>>
>> I've been building Subversion 1.14.0-rc2 on Windows last week, and for
>> doing that I needed to build serf again (1.3.9, but I also tried from
>> branch 1.4.x). I ran into three different problems during that build.
>> I worked around them, but wanted to report them here so perhaps the
>> serf build scripts can be improved.
>>
>> I have scons 3.1.2 and Visual Studio 2019 Community Edition (Version 16.5.3).
>>
>> I'm running this command from within the serf-1.3.9 directory, after I
>> built apr (1.6.5), apr-util (1.6.1), openssl (1.1.1f) and zlib
>> (1.2.11):
>>
>> scons APR=..\apr-1.6.5 APU=..\apr-util-1.6.1
>> OPENSSL=..\openssl-1.1.1f ZLIB=..\zlib-1.2.11
>>
>> 1) Running this with Python 3.8.2 gives this error:
>>
>> [[[
>> scons: Reading SConscript files ...
>> File "C:\research\svn\dev\deps\serf-1.3.9\SConstruct", line 186
>>
>> print 'Warning: Used unknown variables:', ', '.join(unknown.keys())
>>
>> ^
>>
>> SyntaxError: invalid syntax
>> ]]]
>>
>> Putting Python 2.7 in front in my PATH allows it to continue.
>>
>>
>> 2) Now I get this error:
>>
>> [[[
>> scons: Reading SConscript files ...
>>
>> scons: *** Invalid value for option MSVC_VERSION: 14.2. Valid values
>> are: ('14.0', '12.0', '11.0', '10.0', '9.0', '8.0', '6.0')
>> File "C:\research\svn\dev\deps\serf-1.3.9\SConstruct", line 157, in <module>
>> ]]]
>>
>> Interestingly, if I delete the file .saved_config (which actually
>> contains the value "MSVC_VERSION = '14.2'"), scons will continue (and
>> save a new .saved_config file ... i.e. I can always run it if I just
>> remember to delete that file first).
>>
>>
>> 3) Now, linking with openssl 1.1.1f fails:
>>
>> [[[
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> cl /Fobuckets\ssl_buckets.obj /c buckets\ssl_buckets.c /nologo /W4
>> /wd4100 /O2 /MD /DNDEBUG /DWIN32 /DWIN32_LEAN_AND_MEAN /DNOUSER
>> /DNOGDI /DNONLS /DNOCRYPT /DSERF_HAVE_SSPI /I.
>> /IC:\research\svn\dev\deps\httpd-2.4.43\srclib\apr\include
>> /IC:\research\svn\dev\deps\httpd-2.4.43\srclib\apr-util\include
>> /IC:\research\svn\dev\deps\zlib-1.2.11
>> /IC:\research\svn\dev\deps\openssl-1.1.1f\inc32 /Z7
>> ssl_buckets.c
>> buckets\ssl_buckets.c(37): fatal error C1083: Cannot open include
>> file: 'openssl/bio.h': No such file or directory
>> scons: *** [buckets\ssl_buckets.obj] Error 2
>> scons: building terminated because of errors.
>> ]]]
>>
>> The reason is that, as of openssl 1.1.x:
>> * headers are in 'include' rather than 'inc32'
>> * libs come in the root folder of the openssl folder instead of 'out32'
>> * libs are now named libcrypto.lib and libssl.lib instead of
>> libeay32.lib and ssleay32.lib
>>
>> If I patch SConstruct as follows then I can link successfully with
>> openssl 1.1.1.f:
>>
>> [[[
>> --- SConstruct.orig 2020-04-19 15:36:16.257450600 +0200
>> +++ SConstruct 2020-04-19 15:36:51.855740800 +0200
>> @@ -335,7 +335,7 @@
>> LIBPATH=['$ZLIB'])
>>
>> # openssl
>> - env.Append(LIBS=['libeay32.lib', 'ssleay32.lib'])
>> + env.Append(LIBS=['libcrypto.lib', 'libssl.lib'])
>> if not env.get('SOURCE_LAYOUT', None):
>> env.Append(CPPPATH=['$OPENSSL/include/openssl'],
>> LIBPATH=['$OPENSSL/lib'])
>> @@ -343,8 +343,8 @@
>> env.Append(CPPPATH=['$OPENSSL/inc32'],
>> LIBPATH=['$OPENSSL/out32'])
>> else:
>> - env.Append(CPPPATH=['$OPENSSL/inc32'],
>> - LIBPATH=['$OPENSSL/out32dll'])
>> + env.Append(CPPPATH=['$OPENSSL/include'],
>> + LIBPATH=['$OPENSSL'])
>> else:
>> if os.path.isdir(apr):
>> apr = os.path.join(apr, 'bin', 'apr-1-config')
>> ]]]
>>
>> But then it won't work with openssl 1.0.x anymore. So I'm not sure,
>> perhaps the openssl version should be detected and the appropriate
>> configuration should be set accordingly.
>>
>> For some inspiration:
>>
>> - the httpd build requires one to explicitly run:
>> perl srclib\apr\build\cvtdsp.pl -ossl11
>> to build with openssl 1.1.x. So not auto-adapting, but at least it's
>> documented and there is an easy script.
>>
>> - the subversion build auto-detects the openssl version and adapts the
>> necessary include paths and library filenames accordingly. See
>> function _find_openssl() in
>> https://svn.apache.org/repos/asf/subversion/trunk/build/generator/gen_win_dependencies.py
>>
>>
>> After fixing / working around the above three problems I can
>> successfully build serf 1.3.9, phew :-).
>>
>> Thanks,
>> --
>> Johan
