> I claim [1] that loadable modules on OSX are usually called .bundle > or .so, whereas shared libraries are called .dylib.
Check. > as the OpenSSL > engines are loadable modules, and are named .so by the build process, Well, OpenSSL engines are MH_DYLD, *not* MH_BUNDLE. One can argue that it's inappropriate to call them .so, and that it's a bug in build process. But wasn't it what I suggested in my first message? I.e. harmonize extensions in the build process? Or one can argue that it's inappropriate to have them as MH_DYLD and they should be MH_BUNDLE, and that it's a design flaw in OpenSSL... And that there should be different APIs for loading engines and shared libraries (such as zlib)... > the default extension to try to load should be .so even on MacOSX. > another way to resolve this could perhaps be to change to build > process to create files named .dylib, Right. > but given what I read in [1] > that would be a bit strange. Now I see what made you said "trying to dlopen a .dylib is wrong." > [1] > http://www.finkproject.org/doc/porting/porting.en.html#shared.lib-and-mod Is it possible that the information is outdated? 'man dlopen' is explicit: "dlopen -- load and link a dynamic library or bundle." The finkproject.org also talks about "dlopen() emulation" and "an [native] API." About that 'man dlopen' says: "In Mac OS X 10.4, dlopen was rewritten to be a native part of dyld." As mentioned I so far haven't seen any problems dlopen-ing MH_DYLIB. It might depend that I never tried it on pre-10.4. If it turns out that engines *has to* be MH_BUNDLE, then it probably would be more appropriate to introduce dso_dyld.c specifically for MacOS X [as opposite to patching dso_dlfcn.c that is]. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
