Corinna Vinschen <[email protected]> skrev: (24 januari 2016 13:19:00 CET) >On Jan 23 22:12, Richard Levitte wrote: >> In message <[email protected]> on Sat, 23 >Jan 2016 22:01:16 +0100, Corinna Vinschen <[email protected]> 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.
Yes, exactly. The way the engine API was designed from the start, that exact situation is meant to be supported. However, it's been long since I tested that aspect, so I can't personally tell if there's a bit of rot in there. That's certainly worth investigating... > Hilarity ensues. Ok, so, a bit of rot or something other I fail to think of. Do you have details you'd like to share? > 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(*)). Only this >would allow to decouple the engines from a specific versioned DLL. The decoupling of versions is supposed to be between the loading application and the loaded engine, not between them and the libcrypto versions they each use. > > >Corinna > > >(*) On Windows (but NOT Cygwin): LoadLibrary/GetProcAddress. > > >------------------------------------------------------------------------ > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
