Point is that I'd rather see it cross-built by 'make' [which is known to
work at least under cygwin], than by an extra script. In other words you
should be able to get away with single extra mingwx line to ./Configure
and patch for $exe_ext line... No extra scripts should be required...
so you want a Configure based approach, but still using mk1mf.pl,
or do you want native Configure / make / make install based system?
I guess the second option,
Correct.
so I tried implementing it. But I need some
help, as the openssl make system is quite complex, and I don't know
all nuances.
The attached diff should be a step in the right direction.
Can you confirm that 'i586-mingw32msvc-cc -shared' can't be used in
place for dllwrap? And if so why? It works under cygwin... Well, apart
from --def stuff... BTW, what is the exact purpose of this project? If
it's not "provide 100% equivalent replacement for .dll built with
Microsoft C," then why bother with --def?
but
linking libcrypto.dll fails, as there are still references to:
libcrypto.exp:fake:(.edata+0x2964): undefined reference to
`_ENGINE_load_ubsec'
libcrypto.exp:fake:(.edata+0x2f80): undefined reference to
`_ENGINE_load_cswift'
...
even though I used -DOPENSSL_NO_HW.
Well, you have to figure this one out yourself. It's likely to be
something trivial such as left-over from previous attempt without
OPENSSL_NO_HW. If your're positive that it's not the case, then 'rm
crypto/engine/eng_all.o', collect output from make and verify if
-DOPENSSL_NO_HW is actually passed down.
the command that creates this problem is
i586-mingw32msvc-dllwrap --dllname libcrypto.dll \
--output-lib libcrypto.a \
--def ms/libeay32.def libcrypto.a \
-lwsock32 -lgdi32
libcrypto.a is used as both input and output. Is it actually fool-proof? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
