>> Testing OpenSSL 1.0.0a on MacOSX 10.6, I see that it defaults to >> loadable modules using using the .dylib extension. It's my >> understanding this is incorrect, as loadable modules on MacOSX are >> called either .so (for compability) or .bundle (for "native" >> modules). Dynamically linked libraries though are called .dylib, >> but this is not the case for engines. >> >> The OpenSSL build system actually builds and installs the engines as >> .so, but the default loader tries to use .dylib and thus fails to >> load the engine. Diff to fix this issue can be found below and with >> this fix applied, OpenSSL correctly finds and loads the engine. >> > > Well the change was made originally because OpenSSL didn't correctly > load the zlib library dynamically. See this thread: > > http://marc.info/?l=openssl-dev&m=124767425101695&w=2 > > Has the name of the zlib shared library changed now?
This is kind of misleading question... Or rather it's likely to appear of lesser relevance to request initiator... Either way, the thing is that DSO_load is used to load engines' shared objects and reportedly it doesn't work because of extension mismatch. But it's also used by engines themselves to load vendor-provided shared objects. So that the solution to the riddle should be to *harmonize* outcome of engines' build procedure, internal OpenSSL naming *and* 3rd-party naming convention. 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
