Hi Andy, We have standards for the compilers that we use on each platform, and on Windows it is Microsoft's toolset. In our lab we use cygwin for the build framework so that we can use the same framework on Windows and Unix platforms.
What I was trying to say was that rather than using the .bat files and nmake makefiles that come with OpenSSL for Windows builds, we use gcc2cl with cygwin and Microsoft's compiler to piggy-back onto the Unix-ey cygwin build target, thereby avoiding the .bat files and nmake files. We therefore pickup the ability to specify "no-idea no-rc5 no-mdc2" in the same way for Unix and Windows builds, and the same goes for using the -shared option. It just makes the Windows OpenSSL build integrate into our build framework in the same way that the Unix builds do. Yes, it's a standard Win32. By "fairly standard OpenSSL cygwin build" I was referring to the parts of the OpenSSL build process that we are using rather than the compiler. Regards, Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: Tuesday, 11 May 2004 3:13 AM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]