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.
Absolutely.
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 [EMAIL PROTECTED]
