In message <[email protected]> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell <[email protected]> said:
jeremy.farrell> jeremy.farrell> jeremy.farrell> On 15/02/2016 12:29, Richard Levitte wrote: jeremy.farrell> > In message <[email protected]> on Mon, 15 jeremy.farrell> > Feb 2016 13:25:09 +0100, Corinna Vinschen <[email protected]> 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 [email protected] OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
