[openssl-dev] Upcoming build system change

Corinna Vinschen vinschen at redhat.com
Sun Jan 24 14:54:35 UTC 2016


On Jan 24 14:35, Kurt Roeckx wrote:
> On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote:
> > On Jan 23 22:12, Richard Levitte wrote:
> > > 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?

Yes, exactly.  Cygwin is much more trying to be like a Linux distro on
top of Windows.  This includes how we handle shared libs, within the
bounds of [history and] what can be done under Windows, of course.

> So engines build for 1.0.X can be loaded with any
> "cygcrypto-1.0.0.dll"?

Yep.

> > 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.

Ah, good to know.


Thanks,
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/b88bdfb9/attachment.sig>


More information about the openssl-dev mailing list