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

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 majordomo@openssl.org