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

[Richard Levitte]

In message <56C210E7.5080804 at oracle.com> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell <jeremy.farrell at oracle.com> said:

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

In practice, it really doesn't matter, it all comes down what the DSO
module supports, and the way I'm coding this, Configure will decide.
So it's a preference and nothing else.  Me, I don't particularly care,
but if it disturbs the Cygwin community to see one .dll too many, I'm
ready to make the necessary changes (it's literally one line of code
to change).

Cheers,
Richard

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