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>
