[openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw
Richard Levitte
levitte at openssl.org
Mon Feb 15 11:11:26 UTC 2016
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; \
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.
(and, should it come to that, I can see the possibility of making
backward compatibility copies if someone needs it)
vinschen> > This is assuming, btw, that no one mixes the different Windows POSIX
vinschen> > layers on top of each other. If such mixes are commonplace, it's
vinschen> > worth considering, of course...
vinschen>
vinschen> No such mixing is possible due to dependency issues, nor is it
vinschen> supported. You can try but it will not work as desired. Ideally just
vinschen> handle Cygwin as a POSIX system with a few quirks (like having the DLLs
vinschen> in /usr/bin instead of /usr/lib), but otherwise disjunct from native
vinschen> Windows environments. POSIX, not Windows.
Good. Someone else told me "It would take a brave man to mix Cygwin
plugins (engines) with non-Cygwin host or vice versa"... message
received, I don't need to worry about that.
Cheers,
Richard
--
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-dev
mailing list