You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@serf.apache.org by Stefan <lu...@gmx.de> on 2017/03/06 21:55:19 UTC

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

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

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

Regards,
Stefan

[1] http://www.luke1410.de:8090/browse/MAXSVN-83
[2] https://github.com/openssl/openssl/issues/2865

P.S. I'd appreciate to receive replies as CC, since I'm not subscribed
to the serf dev list.



RE: Compiling Serf with OpenSSL 1.1.0

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Stefan [mailto:luke1410@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