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

[Corinna Vinschen]

On Feb 15 12:11, Richard Levitte wrote:
> Hi Corinna,
> 
> 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> >   Cygwin: cygcapi.dll
> vinschen> 
> vinschen> I can't speak for Mingw, but on Cygwin the modules are called libFOO.so,
> vinschen> e.g.
> vinschen> 
> vinschen>   /usr/lib/openssl-1.0.2/engines/libcapi.so
> 
> Really?  I don't understand how that can be.  The link_o.cygwin target
> in Makefile.shared tells me a very different story, with these lines:
> 
> 	SHLIB=cyg$(LIBNAME); \
> 	...
> 	SHLIB_SUFFIX=.dll; \

Well, I fear it's something we could call a "bad hack" in engines/Makefile.
Look at the install target:

  for l in $(LIBNAMES); do \
    ( echo installing $$l; \
      pfx=lib; \
      if expr "$(PLATFORM)" : "Cygwin" >/dev/null; then \
	sfx=".so"; \
	cp cyg$$l.dll $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \
      else \
	[...] \
      fi; \
      chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \
      mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx ); \
  done; \

So the build creates the file as cygFOO.dll and then renames it to
libFOO.so at install time.

However, on second thought, we *could* install the files as cygFOO.dll
into the engines dir, too, because Cygwin's dlopen call is capable to
handle a dlopen call using the usual libFOO.so:

  dlopen ("/usr/lib/openssl-1.0.2/engines/libcapi.so", ...)

Internally it tries to find

  /usr/lib/openssl-1.0.2/engines/libcapi.so
  /usr/lib/openssl-1.0.2/engines/libcapi.dll
  /usr/lib/openssl-1.0.2/engines/cygcapi.dll

in that order, and if any of them exist, it will load it.  This Cygwin
tweak wasn't available back when the above Makefile hack has been
introduced.

OTOH, just keeping it at libFOO.so shouldn't hurt.  First of all
it reduxes confusion when checking for file existence at some other
point in the code.  And second it saves time since trying to find out
if the file exists under another name is extra work we can avoid.

> vinschen> I hope the changes to the build system will keep this intact.
> 
> May I ask why?  The only thing I can see that would depend on the name
> of engines in practice is the DSO module (and that one has no support
> for .dll files in a POSIX context).  I plan on fixing that one to
> match changes I make.

Well, keeping the libFOO.so names for the modules is more POSIXy and
avoids having to change the DSO module.


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/20160215/3b550e0d/attachment-0001.sig>