On Jan 24 13:19, Corinna Vinschen wrote: > On Jan 23 22:12, Richard Levitte wrote: > > In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan > > 2016 22:01:16 +0100, Corinna Vinschen <vinsc...@redhat.com> said: > > > > vinschen> On Jan 23 21:35, Kurt Roeckx wrote: > > vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen > > wrote: > > vinschen> > > > > vinschen> > > Last but not least, we have another problem with enginesdir. > > To allow a > > vinschen> > > rolling release cycle, we have to support multiple versions > > of openssl > > vinschen> > > in parallel. The problem here is that the enginesdir needs > > to be > > vinschen> > > versioned to allow per-openssl version engines. The build > > scripts don't > > vinschen> > > allow for this. Right now we're using a patch as the below > > one to tweak > > vinschen> > > the configury to allow specifying the engines dir during > > build time. > > vinschen> > > Would it hurt terribly to include something like the below > > patch? > > vinschen> > > > vinschen> > In general, I would like to have a directory for the engines > > that > > vinschen> > relates to OSSL_DYNAMIC_OLDEST. > > vinschen> > > vinschen> That probably won't work for Cygwin. The engines are linked > > against the > > vinschen> versioned DLLs of the OpenSSL version they have been built for, > > Even > > vinschen> assuming binary compatibility, an engine linked against > > openssl-1.0 will > > vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1. We > > have to > > vinschen> keep the engines separate. > > > > This is interesting, actually. OSSL_DYNAMIC_OLDEST has some design > > around it that's meant to permit EXACTLY that kind of mixture. It's > > in the macro IMPLEMENT_DYNAMIC_BIND_FN. However, it's possible it's > > not doing enough, and figuring out what else it needs to do is a > > venture I think is worth spending some time on. > > The problem here is Windows and how DLL dependencies are resolved. > We're using versioned DLLs, e.g. > > /usr/bin/cygcrypto-0.9.8.dll > /usr/bin/cygcrypto-1.0.0.dll > /usr/bin/cygcrypto-1.1.dll > > When building engines, the engines are shared libs linking against the > crypto DLL. This creates a hard dependency to the DLL the engine has > been linked against. So, consider using an application linked against > cygcrypto-1.1.dll. It loads an engine built with and thus linked > against cygcrypto-1.0.0.dll. While the application will use functions > from cygcrypto-1.1.dll, the engine will use functions from > cygcrypto-1.0.0.dll. Hilarity ensues. Unless cygcrypto-1.0.0.dll has > been deprecated and removed. In which case loading the engine fails. > > To decouple an engine from a DLL version, what we would have to do is > to change the engines not to link against libcrypto, but rather to load > *all* functions dynamically at runtime (dlload/dlsym(*)).
...in conjunction with symlinks, e.g. dlload ("/usr/lib/libcrypto.so", ...) with /usr/lib/libcrypto.so being a symlink to the latest DLL: /usr/lib/libcrypto.so -> /usr/bin/cygcrypto-1.1.dll Corinna
signature.asc
Description: PGP signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev