[openssl-users] openssl-1.1.0 - Linker error on Windows

[Matt Caswell]

On 25/05/16 15:35, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
>> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To:
>> openssl-users at openssl.org Subject: Re: [openssl-users]
>> openssl-1.1.0 - Linker error on Windows
>> 
>> 
>> On 25/05/16 14:59, Michael Wojcik wrote:
>>> 
>>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org]
>>>> On Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016
>>>> 05:20
>>> 
>>>> I’ve built the openssl-1.1.0 library with no-shared config
>>>> option on Windows.  I’ve linked the library to my application >
>>>> and fixed the few issues with EVP_MD_CTX deprication.  When I
>>>> build my application I get the following link errors:
>>> 
>>>> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved
>>>> external symbol __imp__CertFreeCertificateContext at 4 referenced
>>>> in function _capi_free_key
>>> 
>>> You have the CAPI engine linked into libcrypto (rather than 
>>> configuring it for dynamic loading)
>> 
>> IIRC it is no longer possible to build for static linking but 
>> dynamically load engines (there be dragons).
> 
> Perhaps not. I have a hybrid engine mechanism where I build OpenSSL
> as a static library but as sharable code, link it statically into my
> own shared library (DLL on Windows, shared object on Linux/UNIX), and
> add an engine at runtime. The engine is implemented in my library, so
> it's not actually dynamically loaded, but it isn't statically linked
> into OpenSSL either. That seems to work fine, at least for 1.0.1 and
> 1.0.2.

The problem is that OpenSSL maintains global state. If you've built
OpenSSL as a shared library then any applications or dynamically loaded
engines all load the same shared library and all have the same global state.

If your application is linked statically to OpenSSL and then dynamically
loads engines which are also linked to OpenSSL...then you essentially
get *two* copies of the state! 1.0.1 and 1.0.2 have some hacks to deal
with this for some of the obvious areas where this will cause problems
in engines (e.g. error queues). You can just about get away with it if
you're lucky - but they really are hacks and you could come unstuck in
some corner cases. In 1.1.0 it was decided that that was an untenable
position.

Matt