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

Jeremy Farrell jeremy.farrell at oracle.com
Mon Feb 15 17:54:47 UTC 2016



On 15/02/2016 12:29, Richard Levitte wrote:
> In message <20160215122509.GA15067 at calimero.vinschen.de> on Mon, 15 Feb 2016 13:25:09 +0100, Corinna Vinschen <vinschen at redhat.com> said:
>
> vinschen> On Feb 15 13:03, Richard Levitte wrote:
> vinschen> > So here is what I'm thinking...
> vinschen> >
> vinschen> > - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and
> vinschen> >   whatever suffix is conventional on the platform at hand, be it .so,
> vinschen> >   .dll, .sl, .dylib...)
> vinschen> > - the OpenSSL DSO module should be changed to have the DSO suffix
> vinschen> >   configured instead of having it hardcoded as it is right now (the
> vinschen> >   template framework we use makes that real easy, see how
> vinschen> >   crypto/include/internal/bn_conf.h is generated as an example).
> vinschen> > - the OpenSSL ENGINE module should be changed to tell the DSO module
> vinschen> >   not to prefix the received file name with "lib" (which I suspect is
> vinschen> >   the primary reason for the install hack you mentioned above).
> vinschen> >
> vinschen> > That way, we would have engines that look like DSOs and not like
> vinschen> > shared libraries.  On cygwin, that would be something like "capi.dll",
> vinschen> > on MacOS it would be "capi.dylib", on most other Unixen it would be
> vinschen> > "capi.so".  My intention is to have this work smoothly and
> vinschen> > consistently, without having to resort to all kinds of weird install
> vinschen> > hacks or whatnot.
> vinschen> >
> vinschen> > Does that sounds like an acceptable change to you?
> vinschen>
> vinschen> Any method being platform independent because implementation details are
> vinschen> hidden under the hood sounds perfect to me.
>
> Then it's a go, I'll work on that.  Thanks for your feedback!

It sounds good, except shouldn't it be "capi.so" for cygwin, like the 
other mainstream POSIXy implementations? The point of cygwin is that 
it's POSIX not Windows, and it generally follows common practices of 
POSIXy OSes for things which aren't specified by POSIX. It seems that it 
would be simpler all round (for users as well as development) to treat 
it the same as "normal" UNIX-like OSes except when it absolutely has to 
be treated differently.

-- 
J. J. Farrell - not speaking for Oracle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160215/a105fa4b/attachment-0001.html>


More information about the openssl-dev mailing list