> -----Original Message-----
> From: Stefan [mailto:luke1...@gmx.de]
> Sent: maandag 6 maart 2017 22:55
> To: dev@serf.apache.org
> Subject: Compiling Serf with OpenSSL 1.1.0
>
> Hi,
>
> I tried to get Serf 1.3.9 to compile with OpenSSL 1.1.0(c). Full details
> (including patches I used to build Serf with OpenSSL 1.1.0 are available
> on the MaxSVN issue tracker [1]). Please be aware that the patches are
> not at a quality which would allow them to be integrated directly into
> Serf (since they would break support for OpenSSL 1.0.2).
>
> Due to lack of time atm, I'm just forwarding the basic information so to
> give someone a chance to pick that up and/or build upon the provided
> information.
>
> Issue 1+2: SOURCE_LAYOUT = true/false
> Include directories in OpenSSL 1.1.0 changed. This leads to compile
> errors in Apache Serf:
> "buckets\ssl_buckets.c(37): fatal error C1083: Cannot open include file:
> 'openssl/bio.h': No such file or directory"
> Details on the difference between the two source-layout and the
> implications on the include-structure is described in the MaxSVN issue [1].
+1 to commit your patch for this part to trunk if you change your patch to look
in both locations instead of just the new one. (Just add more items to the same
list on a new line, or something). Removing the old location will break scripts
that expect the current behavior... (Read: my scripts will break ;-))
In general the current (pre-patch) scripts work when more dependencies are
installed to one install location, as is commonly done on *nix, as at least
something else will include that most common install dir...
> Issue 3:
> LINK : fatal error LNK1181: cannot open input file 'libeay32.lib'
> Caused due to library names having changed with OpenSSL 1.1.0 (to:
> libcrypto.lib and libssl.lib).
I would really have to dive back into the scons magic to find out what the best
way would be to resolve this. Perhaps Evgeny's patch shows some temporary
workaround.
> Issue 4:
> Endless loop in CRYPTO_malloc() when running Serf tests.
> This is caused by SSL_library_init() being called after
> OPENSSL_malloc_init(). issue_4.patch [1] provides and possible fix for
> this issue.
>
> Note: Issue 4 was also reported to OpenSSL via GitHub as a possible
> feature improvement to strengthen OpenSSL against this problem [2].
Not exactly sure what we should do here... But if we can we should initialize
libcrypto before libssl, and close things the other way around.
I'm currently unable to upgrade to OpenSSL 1.1.0 myself as I need Cyrus sasl
support in my builds, and that library wasn't updated for OpenSSL 1.1.0 yet as
far as I can tell.
Bert
