>> In other words I'd argue that it's more appropriate to modify >> MacOS-specific build procedure to link engine modules with .dylib. >> As opposite to suggested change to dso_dlfcn.c. > > A .dylib is a shared library - not a loadable module (.bundle/.so). > MacOSX treats those differently, so trying to dlopen a .dylib is > wrong.
Just like on other Unices shared object filename extension does not really have any meaning on MacOS X. Shared library or shared object of any other kind can be called literally anything, it's the content that matters [to dlopen]. And dlopen expects mach-o of MH_DYLIB or MH_BUNDLE type. So that do you refer to? That it's wrong to dlopen(MH_DYLIB)? "Wrong" in which sense? It does work and it does the job... You might imply that OpenSSL engines should be MH_BUNDLEs and it's wrong of OpenSSL to link engine modules as MH_DYLIB. But then you should say just that, not that it's wrong to dlopen *a* .dylib. Also if you mean that, then please tell us (me) why is it wrong or why is it advantageous, because we're not (at least I'm not) really MacOS X experts. Cheers. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
