Question about dynamically loadable engines on Cygwin / Mingw

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
Hi,

I've got a question to the Cygwin / Mingw community, regarding the
naming of dynamic engines.

From looking at Makefile.shared et al, the engines get the same kind
of prefixes as a standard shared library (but without the accompanying
import library, of course).  So the capi engine gets named like this:

  Cygwin: cygcapi.dll
  Mingw: capieay32.dll

Does that mean that using engines with the openssl commands looks
strangely different depending on the platform you happen to be on?
Like, would a run of openssl s_server with the capi engine like
something like this?

  Cygwin: openssl s_server -engine cygcapi.dll ...
  Mingw:  openssl s_server -engine capieay32.dll ...
  Unix:   openssl s_server -engine capi ...

(note that on Unix, it's assumed that the engine *may* be prefixed
with "lib", which might be a reason for discussion as well, as it's
not really meant to be used as a shared library)

Apart from the fact that the current ENGINE framework has no support
for the ".dll" suffix internally (that's an easy fix), is there any
reason to name the dynamic engines anything but, in this example,
capi.dll or libcapi.dll?

This is assuming, btw, that no one mixes the different Windows POSIX
layers on top of each other.  If such mixes are commonplace, it's
worth considering, of course...

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Peter Waltenberg

Possibly the best fix is to simply not specify the library prefix or suffix.

i.e. -engine capi

And let OS/build specific code sort out the rest. You still have .so and .sl on different variants of HP/UX for example.

Next best, specify the complete library name in all cases - and I'll concede, best and second best are pretty equal here.

Pete


-----"openssl-dev" <[hidden email]> wrote: -----
To: [hidden email]
From: Richard Levitte
Sent by: "openssl-dev"
Date: 02/15/2016 10:13AM
Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw

Hi,

I've got a question to the Cygwin / Mingw community, regarding the
naming of dynamic engines.

From looking at Makefile.shared et al, the engines get the same kind
of prefixes as a standard shared library (but without the accompanying
import library, of course).  So the capi engine gets named like this:

  Cygwin: cygcapi.dll
  Mingw: capieay32.dll

Does that mean that using engines with the openssl commands looks
strangely different depending on the platform you happen to be on?
Like, would a run of openssl s_server with the capi engine like
something like this?

  Cygwin: openssl s_server -engine cygcapi.dll ...
  Mingw:  openssl s_server -engine capieay32.dll ...
  Unix:   openssl s_server -engine capi ...

(note that on Unix, it's assumed that the engine *may* be prefixed
with "lib", which might be a reason for discussion as well, as it's
not really meant to be used as a shared library)

Apart from the fact that the current ENGINE framework has no support
for the ".dll" suffix internally (that's an easy fix), is there any
reason to name the dynamic engines anything but, in this example,
capi.dll or libcapi.dll?

This is assuming, btw, that no one mixes the different Windows POSIX
layers on top of each other.  If such mixes are commonplace, it's
worth considering, of course...

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Corinna Vinschen
In reply to this post by Richard Levitte - VMS Whacker-2
Hi Richard,

On Feb 15 01:11, Richard Levitte wrote:

> Hi,
>
> I've got a question to the Cygwin / Mingw community, regarding the
> naming of dynamic engines.
>
> >From looking at Makefile.shared et al, the engines get the same kind
> of prefixes as a standard shared library (but without the accompanying
> import library, of course).  So the capi engine gets named like this:
>
>   Cygwin: cygcapi.dll
I can't speak for Mingw, but on Cygwin the modules are called libFOO.so,
e.g.

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

I hope the changes to the build system will keep this intact.

> This is assuming, btw, that no one mixes the different Windows POSIX
> layers on top of each other.  If such mixes are commonplace, it's
> worth considering, of course...

No such mixing is possible due to dependency issues, nor is it
supported.  You can try but it will not work as desired.  Ideally just
handle Cygwin as a POSIX system with a few quirks (like having the DLLs
in /usr/bin instead of /usr/lib), but otherwise disjunct from native
Windows environments.  POSIX, not Windows.


Thanks,
Corinna

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
Hi Corinna,

In message <[hidden email]> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Corinna Vinschen
On Feb 15 12:11, Richard Levitte wrote:

> Hi Corinna,
>
> In message <[hidden email]> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen <[hidden email]> 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

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 15 Feb 2016 12:39:36 +0100, Corinna Vinschen <[hidden email]> said:

vinschen> On Feb 15 12:11, Richard Levitte wrote:
vinschen> > Hi Corinna,
vinschen> >
vinschen> > In message <[hidden email]> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Corinna Vinschen
On Feb 15 13:03, Richard Levitte wrote:

> 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?
Any method being platform independent because implementation details are
hidden under the hood sounds perfect to me.


Thanks,
Corinna

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 15 Feb 2016 13:25:09 +0100, Corinna Vinschen <[hidden email]> 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!

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

J. J. Farrell-2


On 15/02/2016 12:29, Richard Levitte wrote:
In message [hidden email] on Mon, 15 Feb 2016 13:25:09 +0100, Corinna Vinschen [hidden email] 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.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell <[hidden email]> said:

jeremy.farrell>
jeremy.farrell>
jeremy.farrell> On 15/02/2016 12:29, Richard Levitte wrote:
jeremy.farrell> > In message <[hidden email]> on Mon, 15
jeremy.farrell> > Feb 2016 13:25:09 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 15 Feb 2016 18:59:53 +0100 (CET), Richard Levitte <[hidden email]> said:

levitte> In message <[hidden email]> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell <[hidden email]> said:
levitte>
levitte> jeremy.farrell> It sounds good, except shouldn't it be "capi.so" for
levitte> jeremy.farrell> cygwin, like the other mainstream POSIXy
levitte> jeremy.farrell> implementations? The point of cygwin is that it's
levitte> jeremy.farrell> POSIX not Windows, and it generally follows common
levitte> jeremy.farrell> practices of POSIXy OSes for things which aren't
levitte> jeremy.farrell> specified by POSIX. It seems that it would be simpler
levitte> jeremy.farrell> all round (for users as well as development) to treat
levitte> jeremy.farrell> it the same as "normal" UNIX-like OSes except when it
levitte> jeremy.farrell> absolutely has to be treated differently.
levitte>
levitte> In practice, it really doesn't matter, it all comes down what the DSO
levitte> module supports, and the way I'm coding this, Configure will decide.
levitte> So it's a preference and nothing else.  Me, I don't particularly care,
levitte> but if it disturbs the Cygwin community to see one .dll too many, I'm
levitte> ready to make the necessary changes (it's literally one line of code
levitte> to change).

I had myself a look around in my little installation, and tried these
two commands:

    find /usr/lib -name '*.so'

    find /usr/lib -name '*.dll'

The first one didn't even return a screenfull (in my 25 line terminal
screen), and the overwhelming majority was OpenSSL 1.0.2 engines ;-)

The second one, on the other hand, gave a *lot* more output.  All
aspell, babl, gawk, gegl, perl(!) loadable modules are named with
the FOO.dll naming convention (there are a few packages, a minority,
that have named them cygFOO.dll)...  and the list goes on.

So looking at how things seem to be done normally, I feel confident
that FOO.dll is a sane choice, even though not strictly POSIX in its
file name extension.  And like I said, it matters very little for any
user, the goal is to allow this kind of command line:

    openssl s_server -engine FOO

No extension, just a name for the user to worry about.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

J. J. Farrell-2
On 15/02/2016 23:16, Richard Levitte wrote:
In message [hidden email] on Mon, 15 Feb 2016 18:59:53 +0100 (CET), Richard Levitte [hidden email] said:

levitte> In message [hidden email] on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell [hidden email] said:
levitte> 
levitte> jeremy.farrell> It sounds good, except shouldn't it be "capi.so" for
levitte> jeremy.farrell> cygwin, like the other mainstream POSIXy
levitte> jeremy.farrell> implementations? The point of cygwin is that it's
levitte> jeremy.farrell> POSIX not Windows, and it generally follows common
levitte> jeremy.farrell> practices of POSIXy OSes for things which aren't
levitte> jeremy.farrell> specified by POSIX. It seems that it would be simpler
levitte> jeremy.farrell> all round (for users as well as development) to treat
levitte> jeremy.farrell> it the same as "normal" UNIX-like OSes except when it
levitte> jeremy.farrell> absolutely has to be treated differently.
levitte> 
levitte> In practice, it really doesn't matter, it all comes down what the DSO
levitte> module supports, and the way I'm coding this, Configure will decide.
levitte> So it's a preference and nothing else.  Me, I don't particularly care,
levitte> but if it disturbs the Cygwin community to see one .dll too many, I'm
levitte> ready to make the necessary changes (it's literally one line of code
levitte> to change).

I had myself a look around in my little installation, and tried these
two commands:

    find /usr/lib -name '*.so'

    find /usr/lib -name '*.dll'

The first one didn't even return a screenfull (in my 25 line terminal
screen), and the overwhelming majority was OpenSSL 1.0.2 engines ;-)

The second one, on the other hand, gave a *lot* more output.  All
aspell, babl, gawk, gegl, perl(!) loadable modules are named with
the FOO.dll naming convention (there are a few packages, a minority,
that have named them cygFOO.dll)...  and the list goes on.

So looking at how things seem to be done normally, I feel confident
that FOO.dll is a sane choice, even though not strictly POSIX in its
file name extension.  And like I said, it matters very little for any
user, the goal is to allow this kind of command line:

    openssl s_server -engine FOO

No extension, just a name for the user to worry about.

Thanks Richard - it was just a thought, and clearly not a very helpful one. The rest of the proposal looks like a good improvement to me.
-- 
J. J. Farrell - not speaking for Oracle

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question about dynamically loadable engines on Cygwin / Mingw

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Tue, 16 Feb 2016 01:39:12 +0000, Jeremy Farrell <[hidden email]> said:

jeremy.farrell> Thanks Richard - it was just a thought, and clearly not a very helpful
jeremy.farrell> one. The rest of the proposal looks like a good improvement to me.

Quite all right.  It answered a question that would have been asked
sooner or later, and I much prefer sooner.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev