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