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.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
