[openssl-dev] Upcoming build system change

[Kurt Roeckx]

On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote:
> On Jan 23 22:12, Richard Levitte wrote:
> > In message <20160123210116.GB13479 at calimero.vinschen.de> on Sat, 23 Jan 2016 22:01:16 +0100, Corinna Vinschen <vinschen at 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

So it's name is like the soname on Linux and others?  I'm guessing
only cygwin is doing that and other windows versions still use
things like libeay32.dll?

So engines build for 1.0.X can be loaded with any
"cygcrypto-1.0.0.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(*)).  Only this
> would allow to decouple the engines from a specific versioned DLL.

Note that OSSL_DYNAMIC_OLDEST changed in 1.1.

Even if the engines for 1.1 were compatible with 1.0, we'd have
the same problem on Linux, it also knows to which soname it was
linked.


Kurt