>> 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.

> 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,

Yes, this defines "compatible replacement."

> 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.

If it's not, then when it is:-)

> You've suggested on Friday, that dll names should include version
> number. And this type of build already does this.

We have to think a bit whether or not this naming is appropriate even
for MSC build and harmonize naming conventions between them.

> 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.

Basically I'm not very fond of --export-all. I realize that that's what
happens on Unix, but we probably should change that, i.e. limit symbol
exposure even in Unix (at least where applicable).

> 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.

Note that I've committed rudimentary support for .def this morning, see
http://cvs.openssl.org/chngview?cn=15633. As you justly mention it's not
complete, no, and it received limited testing, but it's a start... At
least I can confirm that I managed to replace MSC .dll with
cross-compiled mingw one and a couple of MSC-compiled test programs I
cared to test actually worked.

> 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.

Care to figure out and tell how to do it with windres and ld? I mean
I've never done this... This one probably doesn't have to be mingw
specific, cygwin people [Corinna?] might appreciate it just as much. A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org