Fail to compile against OpenSSL 1.0.2

[David Woodhouse]

On Wed, 2015-02-11 at 19:31 +0000, Dominyk Tiller wrote:
> The latest OpenSSL 1.0.2 causes OpenConnect to fail to compile. It
> looks
> like it's trying to link into the static libraries rather than dynamic
> libraries on OS X - I don't know if that's expected behaviour or not
> though, so apologies if that's expected.

Apologies for the delayed response. It's kind of expected, yes.

OpenSSL doesn't really have a coherent approach to managing its
dynamical libraries' sonames.

If you give a *specific* directory for OpenSSL, it's quite dangerous to
dynamically link against it — the soname of the dynamic libraries in
that direction might actually *match* the soname of a different build
that's installed where the dynamic linker finds it.

And if the matching libraries *are* installed in the standard place
where the dynamic linker can find them... then surely the headers ought
to be installed in the standard place too, so there shouldn't be any
*need* to specify a location for OpenSSL.

For that reason, we default to *static* linking of you specify an
OpenSSL location. At least, we default to statically linking OpenSSL.

The error you report is what happens when we attempt to create a dynamic
library of our own libopenconnect, linked statically against OpenSSL. We
can't do that.

You should be able to get it to build a *static* libopenconnect.a by
adding '--disable-shared --enable-static' to your configure invocation.

I'll look at making that happen by default when you specify an OpenSSL
location.

This *doesn't* explain https://github.com/Homebrew/homebrew/issues/36641
though. Unless that's caused by some binary incompatibility between two
different OpenSSL dynamic libraries...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150216/fa397e82/attachment.bin>