RE: Win32 compiles under cygwin
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]
Re: Win32 compiles under cygwin
I have one other issue I need resolution on: when I run the make file under cygwin, the resulting libraries are exactly what I get on unix: libssl.a and libcrypto.a. What I want to know is how do I get ssleay32.dll and libeay32.dll? These are required to link m2crypto on Win32. Mark On May 10, 2004, at 5:17 PM, Steven Reddie wrote: 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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]
Re: Win32 compiles under cygwin
Andy Polyakov wrote: 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]
RE: Win32 compiles under cygwin
Mark, When I get time I'll clean up the implementation and post the source to this list. In the meantime I'll send you the binary tomorrow when I'm at work. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jaffe Sent: Monday, 10 May 2004 12:54 PM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin Steven, Thanks for your response. This sounds like it would be an excellent solution to my dilemma. Please feel free to forward your contribution as you see fit. Mark On May 9, 2004, at 5:40 PM, Steven Reddie wrote: Hi Mark, 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. Would this help you in any way? I've tried to contribute it to cygwin but was surprised that there was no interest. We also use it to build OpenLDAP, libxml2, log4cplus, and others almost out-of-the-box. Being able to avoid the OpenSSL .bat files and nmake makefiles helps us to integrate with our cross platform automated build process. Regards, Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jaffe Sent: Monday, 10 May 2004 7:03 AM To: [EMAIL PROTECTED] Subject: Win32 compiles under cygwin Greetings to all. I am responsible to the build environment at OSAF, and we are integrating openssl into the Chandler product. I am concerned about generating the correct configuration, and wonder if someone has a solution. What we do when we incorporate an open-source project into ours is to prepare a script which sets up the configuration for each supported platform (Win32, linux, and OS X for now.) When we run make, it untars the source tarball, applies our patches and then does a configure and a make, installing the libraries into our distribution path. Where I am running into problems is in dealing with the Win32 build situation. We use the cygwin environment, and several of our projects already are compatible in that we call nmake and a DOS-path compatible make file which is working nicely. However, applying this method to the openssl tree has presented some difficulty. I have so far been successful in running a patched ms/32all.bat to generate the required xx.mak files, but the results still contain - style option flags rather than the desired / style. I am stumped at this point. Of course, I could do this under a local command-line but this is not available from remote ssh or in the environment in which we run the tinderbox. Any suggestions? Mark Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ 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]
Re: SHA-256/-384/-512, Netware...
As we all know excludes me so I talked to one of our experts here to find out the answer to your questions. This was his response: [Embedded Response] NetWare supports SSE2 up to a point. NetWare assumes that the XMM registers are scratch registers across procedure calls. NetWare preserves the XMM registers during a pre-emptive context switch. NetWare also does the basic CPU setup so that XMM can be used. Since NetWare 6.X supports Pentium II and newer CPUs, it needs to run on platforms that don't support SSE2. Since NetWare based applications are usually delivered in executable form rather than source code, programs that uses SSE and SSE2 need to detect what type of processor it is running on and adjust accordingly. The 2 main ways of doing this are 1) deliver different versions of the software - one with support for SSE2 and the other without - and have the installation software install the appropriate version; or 2) have the code be dynamic and detect the CPU type when it runs and adjust itself as necessary. [/Embedded Response] I hope that answers the questions. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com Andy Polyakov [EMAIL PROTECTED] 5/6/2004 6:36:06 AM I've handcoded SSE2 SHA512_Transform which exhibits almost 6x performance improvement [of course the result is preliminary] on P4 over gcc compiled code, I've commited the code to CVS even though it's nowhere to plug it in for the moment. The code is therefore subject to change as C implementation is added. But in either case! Following question not directly related to SHA was risen. Adding of SSE2 code required update to crypto/perlasm modules. I've updated x86unix.pl, x86ms.pl and x86nasm.pl, but not the Netware scripts. As we all know SSE requires kernel support (kernel is expected to set-up a privileged control register and preserve xmm content over context switches). Does Netware support SSE in the above sense? Do Netware assemblers support SSE2? In other words is it of actual interest to update Netware scripts? If it is, then I would actually prefer to either merge them to one script or even with x86nasm.pl script. I reckon that differences between them are too small and can be addressed in single script. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Win32 compiles under cygwin
The libssl.a and libcrypto.a binaries are linked to cygwin1.dll. This is not what you want. You do not want to be using the cygwin build process but the MS Visual Studio build environment. Perhaps you can use the cygwin environment to kick off a normal OpenSSL build in the background. Jeffrey Altman Mark Jaffe wrote: I have one other issue I need resolution on: when I run the make file under cygwin, the resulting libraries are exactly what I get on unix: libssl.a and libcrypto.a. What I want to know is how do I get ssleay32.dll and libeay32.dll? These are required to link m2crypto on Win32. Mark On May 10, 2004, at 5:17 PM, Steven Reddie wrote: 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Win32 compiles under cygwin
Exactly what I want to do, but we need a little customization. That's where I ran into problems. Steven Reddie seems to have a solution, hope it works for us. Mark On May 10, 2004, at 6:06 PM, Jeffrey Altman wrote: The libssl.a and libcrypto.a binaries are linked to cygwin1.dll. This is not what you want. You do not want to be using the cygwin build process but the MS Visual Studio build environment. Perhaps you can use the cygwin environment to kick off a normal OpenSSL build in the background. Jeffrey Altman Mark Jaffe wrote: I have one other issue I need resolution on: when I run the make file under cygwin, the resulting libraries are exactly what I get on unix: libssl.a and libcrypto.a. What I want to know is how do I get ssleay32.dll and libeay32.dll? These are required to link m2crypto on Win32. Mark On May 10, 2004, at 5:17 PM, Steven Reddie wrote: 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C
RE: Win32 compiles under cygwin
Jeffrey, Are you saying that using something like gcc2cl to kick off a build the way you do for cygwin, but using the Microsoft compiler, is the wrong way to go? It's working well for us in-house, though we've been using static libraries up until now and are just finishing up changes to support the DLL build. Mark, the naming issue is something that we need to handle also, although we need to use a custom name with the OpenSSL version number included. Whatever we can contribute will include support for altering the name. Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, 11 May 2004 11:07 AM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin The libssl.a and libcrypto.a binaries are linked to cygwin1.dll. This is not what you want. You do not want to be using the cygwin build process but the MS Visual Studio build environment. Perhaps you can use the cygwin environment to kick off a normal OpenSSL build in the background. Jeffrey Altman Mark Jaffe wrote: I have one other issue I need resolution on: when I run the make file under cygwin, the resulting libraries are exactly what I get on unix: libssl.a and libcrypto.a. What I want to know is how do I get ssleay32.dll and libeay32.dll? These are required to link m2crypto on Win32. Mark On May 10, 2004, at 5:17 PM, Steven Reddie wrote: 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] Mark Jaffe | (415) 946-3028 (work) Release Engineer| (408) 807-2093 (cell) OSAF | (415) 946-3001 (FAX) [EMAIL PROTECTED]| http://www.osafoundation.org/ PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE __ OpenSSL
Re: Win32 compiles under cygwin
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. 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. Jeffrey Altman Steven Reddie wrote: Jeffrey, Are you saying that using something like gcc2cl to kick off a build the way you do for cygwin, but using the Microsoft compiler, is the wrong way to go? It's working well for us in-house, though we've been using static libraries up until now and are just finishing up changes to support the DLL build. Mark, the naming issue is something that we need to handle also, although we need to use a custom name with the OpenSSL version number included. Whatever we can contribute will include support for altering the name. Steven smime.p7s Description: S/MIME Cryptographic Signature
RE: Win32 compiles under cygwin
Ok, I understand where you're coming from. What we have works fine, through we've not played around with Kerberos. 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Tuesday, 11 May 2004 12:52 PM To: [EMAIL PROTECTED] Subject: Re: Win32 compiles under cygwin 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. 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. Jeffrey Altman Steven Reddie wrote: Jeffrey, Are you saying that using something like gcc2cl to kick off a build the way you do for cygwin, but using the Microsoft compiler, is the wrong way to go? It's working well for us in-house, though we've been using static libraries up until now and are just finishing up changes to support the DLL build. Mark, the naming issue is something that we need to handle also, although we need to use a custom name with the OpenSSL version number included. Whatever we can contribute will include support for altering the name. Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Can [EMAIL PROTECTED] be removed from the list(s)? (FW: Mail Returned (550 5.1.1 [EMAIL PROTECTED]... User unknown (RCPT)))
I receive one of the following for every message I send to the list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, 11 May 2004 2:08 PM To: Steven Reddie Subject: Mail Returned (550 5.1.1 [EMAIL PROTECTED]... User unknown (RCPT)) Your mail was returned Reason : 550 5.1.1 [EMAIL PROTECTED]... User unknown (RCPT) Returned mail --- From: Steven Reddie [EMAIL PROTECTED] To : [EMAIL PROTECTED] Subject : RE: Win32 compiles under cygwin --- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
