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