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" <openssl-dev-boun...@openssl.org> wrote: -----
To: openssl-dev@openssl.org
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         levi...@openssl.org
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 via email to