Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
> From: openssl-users [mailto:openssl-users-boun...@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-boun...@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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
On 25/05/16 15:35, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On >> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To: >> openssl-users@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-boun...@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@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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
-Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Wojcik Sent: 25 May 2016 15:35 To: openssl-users@openssl.org Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:05 > To: openssl-users@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-boun...@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@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. (Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.) > >, so you need to link against the > > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > >when you create libcrypto or when you link your application. > > Another possibility, if you are not using the CAPI engine, is to > disable it during the OpenSSL build using the no-capieng Configure option. Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course. I've switched it off via the configure options. All working fine now thank you. Andrew __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:05 > To: openssl-users@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-boun...@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@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. (Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.) > >, so you need to link against the > > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > > when you create libcrypto or when you link your application. > > Another possibility, if you are not using the CAPI engine, is to disable > it during the OpenSSL build using the no-capieng Configure option. Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
[Ugh, HTML email, which Outlook is still incapable of processing correctly.] > From: openssl-users [mailto:openssl-users-boun...@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@4 referenced in function _capi_free_key You have the CAPI engine linked into libcrypto (rather than configuring it for dynamic loading), so you need to link against the Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either when you create libcrypto or when you link your application. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
On 25/05/16 14:59, Michael Wojcik wrote: > [Ugh, HTML email, which Outlook is still incapable of processing > correctly.] > >> From: openssl-users [mailto:openssl-users-boun...@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@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). >, so you need to link against the > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > when you create libcrypto or when you link your application. > Another possibility, if you are not using the CAPI engine, is to disable it during the OpenSSL build using the no-capieng Configure option. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
