On 2006.10.20 at 15:10:06 +0200, Andy Polyakov wrote: > I personally have no problems with that, but formally we should ask > ourselves what is the goal of this effort? To produce *some* .dll or to > produce *100% compatible replacement* .dll for MSC build? If latter, > then we have to get .def working. If former, we can as well settle for > --export-all. A.
We have to clarify what we mean under "100% compatible replacement". If we want to have DLL's which can be used with existing binary applications, build with MSVC, than generating proper .def file is not only thing to do. We have also maintain same dll names. Now MingW build with Unix configure system doesn't produce same DLL names as MSVC build. And might be, it is time to make change. You've suggested on Friday, that dll names should include version number. And this type of build already does this. But, if we just want to produce dll's and import libraries, which can be used to recompile applications with MSVC from sources, --export-all solves this problem. Really my modifications to Makefile.shared which make it call mkdef.pl and then link produced .def file into dll are very ugly. So if we can avoid including them into core CVS better to go this way. But there is another problem which Unix-style Configure doesn't solve now: dll can include VERSION_INFO resource. Now Configure creates .rc file only if IsMK1MF is set. I think that if we want to have native Win32 dll, we should include this resource, even if build environment is completely Unix-style. This resource greatly simplifies debugging of deployed application. It is quite easy to explain to user over phone to right-click on the DLL, look into proprieties of the file and dictate exact build number of DLL to support personnel. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
