Since the cygwin environment is different from the MS Run Time environment, I would not make the assumption that the binaries produced use exactly the same configuration options. They may but I would not count on it.
Well, it's all about control and understanding. I mean if we manage to understand exactly what's going on, we can make it do what we want:-) Actually the idea of using Unix-like make, cygwin or DJGPP, to invoke cl is rather attractive and I don't think it's impossible. I even fail to see why does it have to be a gcc2cl front-end... It should be possible to invoke cl directly [note that cl is rather forgiving when it comes to path specifications, e.g. -I../include works as well as -I..\\include]. Of course you need gcc2cl for autoconf purposes, but in OpenSSL context it should be possible to make it work with cl directly...
I understand what you are attempting to do; I just do not know if the results will be the same. I know that with other packages such as Kerberos you absolutely do not get the same result when building under cygwin because the environment is more Unix like and therefore different assumptions are made.
What make may not do is to reset INCLUDE and LIB variables and do something completely different in place for ar, e.g. it can as well generate a linker answer file to be used when generating .dll. And one have to add extra rules, most notably .c.obj.
Steven,
I've created a new "CygwinMSVC" entry in Configure which uses enough of the Cygwin entry to integrate with the rest of the build framework, but uses a SYSNAME of WIN32 (not CYGWIN32) and sets other defines such as DSO_WIN32 so that it picks up the Microsoft-specific stuff.
Can you post the line? How do you resolve the ar issue? A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
