Steven,
I've written a command-line utility called gcc2cl which acts like a gcc
front-end while using Microsoft's compiler/linker at the backend. It
translates options and does some munging of cl's stdout/stderr so as to fool
autoconf into thinking it is really using gcc. This enables us (I did this
at Computer Associates) to do a fairly standard OpenSSL cygwin build while
using the Microsoft compiler/linker/libraries/runtime.
Could you elaborate on "fairly standard OpenSSL cygwin build." What's considered "standard"? I assume the way Cygwin is currently supported by OpenSSL... What's "fair"? What is the actual reason for dismissing gcc and trying to compile cygwin library with Microsoft compiler? Trouble is that Microsoft compiler generates code which is dependent on presence of Visual C run-time environment and it's a slippery way. Presense of 3rd party run-time components in a cygwin application might break some interfaces [fork is first one to come to mind].
Of course you might mean that the only cygwin component you use is make and sh [which is actually appealing!] and that resulting OpenSSL build does not contain any run-time dependencies from cygwin1.dll. But can you call it "fairly standard *cygwin* build"? Shouldn't it be called "fairly standard *Win32* build"? A.
I believe the OSAF requires a build which has no dependencies on cygwin1.dll. I may very well be wrong but I believe that they are simply using the cygwin environment as a means to remote login via SSH for the purpose of automating the execution of the build process on Windows in a manner equivalent to that which is done on their supported Unix/Linux systems.
Jeffrey Altman
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
