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

2016-02-15 Thread Richard Levitte 
In message <56c27dc0.3030...@oracle.com> on Tue, 16 Feb 2016 01:39:12 +, 
Jeremy Farrell  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Jeremy Farrell 

On 15/02/2016 23:16, Richard Levitte wrote:

In message <20160215.185953.117619649162395329.levi...@openssl.org> on Mon, 15 Feb 
2016 18:59:53 +0100 (CET), Richard Levitte  said:

levitte> In message <56c210e7.5080...@oracle.com> on Mon, 15 Feb 2016 17:54:47 +, 
Jeremy Farrell  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

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

2016-02-15 Thread Richard Levitte 
In message <20160215.185953.117619649162395329.levi...@openssl.org> on Mon, 15 
Feb 2016 18:59:53 +0100 (CET), Richard Levitte  said:

levitte> In message <56c210e7.5080...@oracle.com> on Mon, 15 Feb 2016 17:54:47 
+, Jeremy Farrell  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Richard Levitte 
In message <56c210e7.5080...@oracle.com> on Mon, 15 Feb 2016 17:54:47 +, 
Jeremy Farrell  said:

jeremy.farrell> 
jeremy.farrell> 
jeremy.farrell> On 15/02/2016 12:29, Richard Levitte wrote:
jeremy.farrell> > In message <20160215122509.ga15...@calimero.vinschen.de> on 
Mon, 15
jeremy.farrell> > Feb 2016 13:25:09 +0100, Corinna Vinschen 
 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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

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

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

2016-02-15 Thread Jeremy Farrell 



On 15/02/2016 12:29, Richard Levitte wrote:

In message <20160215122509.ga15...@calimero.vinschen.de> on Mon, 15 Feb 2016 13:25:09 
+0100, Corinna Vinschen  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

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

2016-02-15 Thread Richard Levitte 
In message <20160215122509.ga15...@calimero.vinschen.de> on Mon, 15 Feb 2016 
13:25:09 +0100, Corinna Vinschen  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread 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


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Richard Levitte 
In message <20160215113936.ga9...@calimero.vinschen.de> on Mon, 15 Feb 2016 
12:39:36 +0100, Corinna Vinschen  said:

vinschen> On Feb 15 12:11, Richard Levitte wrote:
vinschen> > Hi Corinna,
vinschen> > 
vinschen> > In message <20160215105045.ga7...@calimero.vinschen.de> on Mon, 15 
Feb 2016 11:50:45 +0100, Corinna Vinschen  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Corinna Vinschen 
On Feb 15 12:11, Richard Levitte wrote:
> Hi Corinna,
> 
> In message <20160215105045.ga7...@calimero.vinschen.de> on Mon, 15 Feb 2016 
> 11:50:45 +0100, Corinna Vinschen  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


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Richard Levitte 
Hi Corinna,

In message <20160215105045.ga7...@calimero.vinschen.de> on Mon, 15 Feb 2016 
11:50:45 +0100, Corinna Vinschen  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Corinna Vinschen 
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


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2016-02-15 Thread Peter Waltenberg 
 Possibly the best fix is to simply not specify the library prefix or suffix.i.e. -engine capiAnd 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"  wrote: -To: openssl-dev@openssl.orgFrom: Richard Levitte Sent by: "openssl-dev" Date: 02/15/2016 10:13AMSubject: [openssl-dev] Question about dynamically loadable engines on Cygwin/ MingwHi,I've got a question to the Cygwin / Mingw community, regarding thenaming of dynamic engines.From looking at Makefile.shared et al, the engines get the same kindof prefixes as a standard shared library (but without the accompanyingimport library, of course).  So the capi engine gets named like this:  Cygwin: cygcapi.dll  Mingw: capieay32.dllDoes that mean that using engines with the openssl commands looksstrangely different depending on the platform you happen to be on?Like, would a run of openssl s_server with the capi engine likesomething 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 prefixedwith "lib", which might be a reason for discussion as well, as it'snot really meant to be used as a shared library)Apart from the fact that the current ENGINE framework has no supportfor the ".dll" suffix internally (that's an easy fix), is there anyreason 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 POSIXlayers on top of each other.  If such mixes are commonplace, it'sworth considering, of course...Cheers,Richard-- Richard Levitte         levi...@openssl.orgOpenSSL Project         http://www.openssl.org/~levitte/-- openssl-dev mailing listTo unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

2016-02-14 Thread Richard Levitte 
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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev