[openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw

[Richard Levitte]

In message <20160215113936.GA9749 at calimero.vinschen.de> on Mon, 15 Feb 2016 12:39:36 +0100, Corinna Vinschen <vinschen at redhat.com> said:

vinschen> On Feb 15 12:11, Richard Levitte wrote:
vinschen> > Hi Corinna,
vinschen> > 
vinschen> > In message <20160215105045.GA7601 at calimero.vinschen.de> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen <vinschen at redhat.com> said:
vinschen> > 
vinschen> > vinschen> >   Cygwin: cygcapi.dll
vinschen> > vinschen> 
vinschen> > vinschen> I can't speak for Mingw, but on Cygwin the modules are called libFOO.so,
vinschen> > vinschen> e.g.
vinschen> > vinschen> 
vinschen> > vinschen>   /usr/lib/openssl-1.0.2/engines/libcapi.so
vinschen> > 
vinschen> > Really?  I don't understand how that can be.  The link_o.cygwin target
vinschen> > in Makefile.shared tells me a very different story, with these lines:
vinschen> > 
vinschen> > 	SHLIB=cyg$(LIBNAME); \
vinschen> > 	...
vinschen> > 	SHLIB_SUFFIX=.dll; \
vinschen> 
vinschen> Well, I fear it's something we could call a "bad hack" in engines/Makefile.
vinschen> Look at the install target:
vinschen> 
vinschen>   for l in $(LIBNAMES); do \
vinschen>     ( echo installing $$l; \
vinschen>       pfx=lib; \
vinschen>       if expr "$(PLATFORM)" : "Cygwin" >/dev/null; then \
vinschen> 	sfx=".so"; \
vinschen> 	cp cyg$$l.dll $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \
vinschen>       else \
vinschen> 	[...] \
vinschen>       fi; \
vinschen>       chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \
vinschen>       mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx ); \
vinschen>   done; \
vinschen> 
vinschen> So the build creates the file as cygFOO.dll and then renames it to
vinschen> libFOO.so at install time.

Ew, hadn't noticed that.  But ok, an install time thing, and
supposedly because there was no support whatsoever for the ".dll"
suffix or "cyg" prefix in crypto/dso/dso_dlfcn.c (still isn't)

vinschen> However, on second thought, we *could* install the files as cygFOO.dll
vinschen> into the engines dir, too, because Cygwin's dlopen call is capable to
vinschen> handle a dlopen call using the usual libFOO.so:
vinschen> 
vinschen>   dlopen ("/usr/lib/openssl-1.0.2/engines/libcapi.so", ...)
vinschen> 
vinschen> Internally it tries to find
vinschen> 
vinschen>   /usr/lib/openssl-1.0.2/engines/libcapi.so
vinschen>   /usr/lib/openssl-1.0.2/engines/libcapi.dll
vinschen>   /usr/lib/openssl-1.0.2/engines/cygcapi.dll

Interesting hack.

vinschen> > May I ask why?  The only thing I can see that would depend on the name
vinschen> > of engines in practice is the DSO module (and that one has no support
vinschen> > for .dll files in a POSIX context).  I plan on fixing that one to
vinschen> > match changes I make.
vinschen> 
vinschen> Well, keeping the libFOO.so names for the modules is more POSIXy and
vinschen> avoids having to change the DSO module.

Mmm, libFOO.so is POSIXy...  for shared libraries that are intended to
be linked against using cc / ld -l option.  However, the trend is that
DSOs that are meant to be loaded dynamically by a program (in other
words, plugins) need not be named in that way, and I'd argue further
that they *shouldn't*, so as not to be confused with shared libraries.

So here is what I'm thinking...

- engines in 1.1 should be named FOO.{suffix} (for an engine FOO and
  whatever suffix is conventional on the platform at hand, be it .so,
  .dll, .sl, .dylib...)
- the OpenSSL DSO module should be changed to have the DSO suffix
  configured instead of having it hardcoded as it is right now (the
  template framework we use makes that real easy, see how
  crypto/include/internal/bn_conf.h is generated as an example).
- the OpenSSL ENGINE module should be changed to tell the DSO module
  not to prefix the received file name with "lib" (which I suspect is
  the primary reason for the install hack you mentioned above).

That way, we would have engines that look like DSOs and not like
shared libraries.  On cygwin, that would be something like "capi.dll",
on MacOS it would be "capi.dylib", on most other Unixen it would be
"capi.so".  My intention is to have this work smoothly and
consistently, without having to resort to all kinds of weird install
hacks or whatnot.

Does that sounds like an acceptable change to you?

(also, I'm thinking that engines should never be expected to exist
along LD_LIBRARY_PATH.  That environment variable is for shared
libraries, not for DSOs...  it's not a hard opinion, though)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/