[openssl-dev] Upcoming build system change

[Corinna Vinschen]

On Jan 24 13:19, 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
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160124/a248ba07/attachment.sig>