> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:52 > > 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: > >> > >> 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! Ah. That's not a problem in my case, since both OpenSSL and my engine code are statically linked into a single shared library. Everyone's using the same single copy of OpenSSL. The engine is added to OpenSSL at runtime (if it's needed) as if it were dynamically loaded, but it was there all along. And while we statically link OpenSSL into our own library, it's built for sharing and our library is shared. We're just not supplying libcrypto and libssl as discrete modules. (We're very familiar with the issues around shared-library collisions, thanks to decades of dealing with things like Microsoft's broken C runtime, Oracle's inclusion of OpenLDAP in their client, and so on.) -- Michael Wojcik Technology Specialist, Micro Focus
