In message <[EMAIL PROTECTED]> on Thu, 13 Oct 2005 22:51:13 +0200, Andy Polyakov <[EMAIL PROTECTED]> said:
appro> 1. One can "cook" some #ifdef spaghetti in dso_dlfcn.c [and appro> others as required]. appro> 2. One can fix affected link_o targets to adhere to suffix appro> hardcoded in corresponding dso module. appro> 3. One can pick alternative suffix for dynamically loadable appro> objects, e.g. .eng, and use it on *all* platforms. appro> appro> I'd personally prefer the last alternative. I'd even scrap the appro> prefix... Is there a platform which would fail to dynamically appro> load object with arbitrary extension? It's not a problem on appro> Unices nor Windows... What about VMS? But this option is appro> appropriate for next major release. My second preference is #2. A. It can probably be done on VMS as well, but would be regarded as *highly* irregular. On VMS, the normal extension for shared libraries is .EXE, unconditionally. I doubt you will ever find a shared library on VMS with a different extension. Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
