This is a discussion on Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32) - Openssl ; >> 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, >> ...
>> 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
> 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
> 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 email@example.com
Automated List Manager firstname.lastname@example.org