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]

Reply via email to