Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
>> There is no assembly support for pe64. > > Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules. > There is no support for GNU assembler under Win64, but masm (rather > known as ml64) and nasm are fully supported (though there are > requirements for least supported versions, for nasm it's 2.03). > >> So no assembly is available. > > If assembler was to be added to mingw64, I'd rather deploy nasm. It > would be easiest. Just for public reference. It turned to be impossible to deploy nasm-generated modules with mingw64 as is. This is because mingw64 apparently adheres to Win32-like symbol decoration, and as result mingw64 object modules are symbol incompatible and can't be linked with objects targeting Microsoft C. For example, C function named "foo" would be denoted by symbol "_foo" by mingw64, but "foo" - by MSC, corresponding dll import would be denoted by "__imp__foo" by mingw64, but "__imp_foo" - by MSC. As something had to be done I've chosen to add "native" support for mingw64 to x86_64-xlate.pl [as opposite to adapting nasm code generator for mingw64]. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hello, appro added assembly support for mingw64 at [1]. I've succeeded in compiling this with the following patch. Thank you! Alon. [1] http://cvs.openssl.org/chngview?cn=17619 --- --- openssl-SNAP-20081113/Configure 2008-11-12 22:00:07.0 +0200 +++ openssl-SNAP-20081113.new/Configure 2008-11-13 17:46:39.0 +0200 @@ -492,7 +492,7 @@ my %table=( # MinGW "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::MINGW32:-lws2_32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_asm}:coff:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a", -"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE:::MINGW64:-lws2_32 -lgdi32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${no_asm}:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a", +"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE:::MINGW64:-lws2_32 -lgdi32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${x86_64_asm}:mingw64:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a", # UWIN "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", --- openssl-SNAP-20081113/crypto/bn/asm/x86_64-gcc.c2008-11-12 11:00:09.0 +0200 +++ openssl-SNAP-20081113.new/crypto/bn/asm/x86_64-gcc.c2008-11-13 17:54:51.0 +0200 @@ -54,7 +54,11 @@ *machine. */ +#ifdef _WIN64 +#define BN_ULONG unsigned long long +#else #define BN_ULONG unsigned long +#endif /* * "m"(a), "+m"(r) is the way to favor DirectPath �-code; __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
On 11/3/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: > Why "mingw64" ... -D_WIN32_WINNT=0x333 ? > > This has to defined by openssl headers (if not defined) to 0x400. > HEAD version is for winsock2 and I'm not sure that winsock2 is available as > example for ancient nt3.51. The winsock2 library is -lws2_32 . It was in the original patch, I did not change this. 0x400 is good. Alon. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Alon Bar-Lev via RT wrote: On 10/31/08, Andy Polyakov via RT <[EMAIL PROTECTED]> wrote: Could you please test the other suggested bn_lcl.h modification? While you're on it... [SNIP] Attached is a new patch. Thanks! Alon. Why "mingw64" ... -D_WIN32_WINNT=0x333 ? This has to defined by openssl headers (if not defined) to 0x400. HEAD version is for winsock2 and I'm not sure that winsock2 is available as example for ancient nt3.51. The winsock2 library is -lws2_32 . Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Great! Can you commit the mingw64 other stuff? On 11/1/08, Andy Polyakov via RT <[EMAIL PROTECTED]> wrote: > >> I managed to produce them myself with > >> mingw-w64-bin_x86-64-linux_20080921.tar.bz2. Modified sha512.c is fine, > > > > Great! > > My environment is gcc-4.3.2, binutils-CVS-head, mingw-w64-SVN-head as > > > 20080921 is equipped with gcc-4.4.0 and whatever the rest it is equipped > with. > > > >> modified bn_lcl.h gives ~2x improvement. All tests pass except for the > >> last Whirlpool test. It's a compiler bug, because if I drop optimization > >> level to -O1 when compiling wp_block.c, the test passes. > > > > Can you please send this hank as attachment? > > > http://cvs.openssl.org/chngview?cn=17580. > > > >> Strangely enough the code in question is not compiled in VC-* build... > >> Basically there is no need for GetModuleHandle("avdapi32") and > >> consequent GetProcAddress calls, because the functions in question are > >> present on all WinNT *and* Win9x. On latter they do nothing, but they > >> are present, so that application won't suffer from startup errors if you > >> link them explicitly. > > > > So do we need it or don't we? > > > http://cvs.openssl.org/chngview?cn=17583. A. > > > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
>> I managed to produce them myself with >> mingw-w64-bin_x86-64-linux_20080921.tar.bz2. Modified sha512.c is fine, > > Great! > My environment is gcc-4.3.2, binutils-CVS-head, mingw-w64-SVN-head as 20080921 is equipped with gcc-4.4.0 and whatever the rest it is equipped with. >> modified bn_lcl.h gives ~2x improvement. All tests pass except for the >> last Whirlpool test. It's a compiler bug, because if I drop optimization >> level to -O1 when compiling wp_block.c, the test passes. > > Can you please send this hank as attachment? http://cvs.openssl.org/chngview?cn=17580. >> Strangely enough the code in question is not compiled in VC-* build... >> Basically there is no need for GetModuleHandle("avdapi32") and >> consequent GetProcAddress calls, because the functions in question are >> present on all WinNT *and* Win9x. On latter they do nothing, but they >> are present, so that application won't suffer from startup errors if you >> link them explicitly. > > So do we need it or don't we? http://cvs.openssl.org/chngview?cn=17583. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
On 11/1/08, Andy Polyakov via RT <[EMAIL PROTECTED]> wrote: > >> Could you please test the other suggested bn_lcl.h modification? While > >> you're on it... > > > > I cannot actually test it... I can compile and users may test. > > I don't have a win64 machine. > > > How is it tested? Implicitly by an application being inter-operable with > another? Meaning that only only part of algorithms is tested... I sent them the sha512t test from OpenSSL output. > I managed to produce them myself with > mingw-w64-bin_x86-64-linux_20080921.tar.bz2. Modified sha512.c is fine, Great! My environment is gcc-4.3.2, binutils-CVS-head, mingw-w64-SVN-head as I found many issues in older releases. > modified bn_lcl.h gives ~2x improvement. All tests pass except for the > last Whirlpool test. It's a compiler bug, because if I drop optimization > level to -O1 when compiling wp_block.c, the test passes. Can you please send this hank as attachment? > Strangely enough the code in question is not compiled in VC-* build... > Basically there is no need for GetModuleHandle("avdapi32") and > consequent GetProcAddress calls, because the functions in question are > present on all WinNT *and* Win9x. On latter they do nothing, but they > are present, so that application won't suffer from startup errors if you > link them explicitly. So do we need it or don't we? Thanks! Alon. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
>> Could you please test the other suggested bn_lcl.h modification? While >> you're on it... > > I cannot actually test it... I can compile and users may test. > I don't have a win64 machine. How is it tested? Implicitly by an application being inter-operable with another? Meaning that only only part of algorithms is tested... > And I don't know how exactly I can check for speed... Same as on unix: openssl speed . > I can send you binaries to test if you like. I managed to produce them myself with mingw-w64-bin_x86-64-linux_20080921.tar.bz2. Modified sha512.c is fine, modified bn_lcl.h gives ~2x improvement. All tests pass except for the last Whirlpool test. It's a compiler bug, because if I drop optimization level to -O1 when compiling wp_block.c, the test passes. >> >> Also. As NT is natively UNICODE, and there are no non-NT Win64 >> >> implementations(*), there is no reason to favor legacy ANSI interfaces. >> >> Could you verify that it compiles and works with -DUNICODE -D_UNICODE >> >> added to config line? >> > >> > Except one modification I had to do, updated in the patch. Strangely enough the code in question is not compiled in VC-* build... Basically there is no need for GetModuleHandle("avdapi32") and consequent GetProcAddress calls, because the functions in question are present on all WinNT *and* Win9x. On latter they do nothing, but they are present, so that application won't suffer from startup errors if you link them explicitly. >> Quoting util/VC-32.pl: "As per 0.9.8 release remaining warnings were >> explicitly examined and considered safe to ignore." It naturally does >> not necessarily apply to HEAD, but there is awareness of the problem. > > Well... I don't run this script :) I was just trying to say that the question was posed and looked into. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
On 10/31/08, Andy Polyakov via RT <[EMAIL PROTECTED]> wrote: > Could you please test the other suggested bn_lcl.h modification? While > you're on it... I cannot actually test it... I can compile and users may test. I don't have a win64 machine. And I don't know how exactly I can check for speed... I can send you binaries to test if you like. > >>> I am not fully sure that the crypto/sha/sha512.c is correct, it > >>> simulate the behavior of win64 using Microsoft compiler, using > >>> _rotr64 function as ROTR. > >> What you should have done instead is to modify macro in question > >> declaring ret as unsigned long long. If it doesn't work, then it's more > >> appropriate to leave ROTR undefined, i.e. *not* using _rotr64. Please > >> verify. > > > > Thanks, I converted this to SHA_LONG64 and it now compiles. > > > Can you confirm that it even passes the test? I mean mere compilation > success doesn't qualify, it has to pass the test. I will ask my users to run the sha512 test. > > >> Also. As NT is natively UNICODE, and there are no non-NT Win64 > >> implementations(*), there is no reason to favor legacy ANSI interfaces. > >> Could you verify that it compiles and works with -DUNICODE -D_UNICODE > >> added to config line? > > > > > This is too much work, > > > Adding couple of words to config line? I tried to... But then got many linkage error messages of _OBJ_ something. Strange... Now I tried it on clean tree with same snapshot and it compiles. Except one modification I had to do, updated in the patch. > Quoting util/VC-32.pl: "As per 0.9.8 release remaining warnings were > explicitly examined and considered safe to ignore." It naturally does > not necessarily apply to HEAD, but there is awareness of the problem. Well... I don't run this script :) Attached is a new patch. Thanks! Alon. diff -urNp openssl-SNAP-20081003/Configure openssl-SNAP-20081003.mingw64/Configure --- openssl-SNAP-20081003/Configure 2008-09-16 00:00:05.0 +0300 +++ openssl-SNAP-20081003.mingw64/Configure 2008-10-20 12:37:37.0 +0200 @@ -496,6 +496,8 @@ my %table=( # MinGW "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::MINGW32:-lws2_32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a", +"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -Wall -D_WIN32_WINNT=0x333:::MINGW64:-lws2_32 -lgdi32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${no_asm}:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a", + # UWIN "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", @@ -968,7 +970,7 @@ foreach (sort (keys %disabled)) my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds; -$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target eq "mingw"); +$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target =~ /^mingw/); $exe_ext=".nlm" if ($target =~ /netware/); $exe_ext=".pm" if ($target =~ /vos/); $openssldir="/usr/local/ssl" if ($openssldir eq "" and $prefix eq ""); --- openssl-SNAP-20081003/engines/e_aep.c 2008-01-04 01:01:24.0 +0200 +++ openssl-SNAP-20081003.mingw64/engines/e_aep.c 2008-10-20 12:46:24.0 +0200 @@ -62,8 +62,10 @@ #include #else #include +#ifndef _PID_T_ typedef int pid_t; +#endif #endif #if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_CLIB) #define getpid GetThreadID diff -urNp openssl-SNAP-20081028.org/crypto/sha/sha512.c openssl-SNAP-20081028/crypto/sha/sha512.c --- openssl-SNAP-20081028/crypto/sha/sha512.c 2008-04-24 13:00:12.0 +0300 +++ openssl-SNAP-20081028.mingw64/crypto/sha/sha512.c 2008-10-30 22:41:20.0 +0200 @@ -350,7 +350,7 @@ static const SHA_LONG64 K512[80] = { #ifndef PEDANTIC # if defined(__GNUC__) && __GNUC__>=2 && !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_NO_INLINE_ASM) # if defined(__x86_64) || defined(__x86_64__) -# define ROTR(a,n) ({ unsigned long ret; \ +# define ROTR(a,n) ({ SHA_LONG64 ret; \ asm ("rorq %1,%0" \ : "=r"(ret) \ : "J"(n),"0"(a) \ --- openssl-SNAP-20081028/apps/speed.c 2008-10-30 22:59:03.0 +0200 +++ openssl-SNAP-20081028.mingw64/apps/speed.c 2008-10-30 22:59:16.0 +0200 @@ -281,7 +281,7 @@ static double Time_F(int s) if (thr==NULL) { DWORD ret=GetLastError(); - BIO_printf(bio_err,"unable to CreateThread (%d)",ret); + BIO_printf(bio_err,"unable to CreateThread (%ld)",ret); ExitProcess(ret); } CloseHandle(thr); /* detach the thread */ --- openssl-SNAP-20081028/crypto/bio/bss_log.c 2008-10-31 14:32:17.0 +0200 +++ openssl-SNAP-20081028.mingw64/crypto/bio/bss_log.c 2008-10-31 14:24:51.0 +0200 @@ -71,6 +71,7 @@ #if defined(OPENSSL_SYS_WINCE) #elif defined(OPENSSL_SYS_WIN32) # include +# include #elif defined(OPENSSL_SYS_VMS) # incl
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Could you please test the other suggested bn_lcl.h modification? While you're on it... >>> I am not fully sure that the crypto/sha/sha512.c is correct, it >>> simulate the behavior of win64 using Microsoft compiler, using >>> _rotr64 function as ROTR. >> What you should have done instead is to modify macro in question >> declaring ret as unsigned long long. If it doesn't work, then it's more >> appropriate to leave ROTR undefined, i.e. *not* using _rotr64. Please >> verify. > > Thanks, I converted this to SHA_LONG64 and it now compiles. Can you confirm that it even passes the test? I mean mere compilation success doesn't qualify, it has to pass the test. >> Also. As NT is natively UNICODE, and there are no non-NT Win64 >> implementations(*), there is no reason to favor legacy ANSI interfaces. >> Could you verify that it compiles and works with -DUNICODE -D_UNICODE >> added to config line? > > This is too much work, Adding couple of words to config line? > and it is not related to mingw-win64, as this is needed > also for NT port. There is too much dependency in ANSI in current > implementation. VC-WIN64* and VC-CE are compiled with UNICODE. It's supported option in openssl. > I forgot to mention that the uplink was removed due to assembly issues. > > There is another issue... sizeof(long) more places > that needs some attention, the "Should be fixed" category probably impact > more than > I can fix. Alignments are simple to fix, but changing the long variables that > hold pointers > modifies interfaces. Quoting util/VC-32.pl: "As per 0.9.8 release remaining warnings were explicitly examined and considered safe to ignore." It naturally does not necessarily apply to HEAD, but there is awareness of the problem. > I just don't understand how using Microsoft compiler this code makes > sense. It doesn't. It's just that casting of pointer to narrower type does not necessarily constitute a bug (most notably when casted value is not casted back to pointer) and as per above it was conscious choice in time-pressed release situation. In addition one should note that gcc makes you more nervous, because it's overzealous about pointer to integer conversion even(!) with explicit casts. Most notably when you say "I know what I'm doing" and write explicit int foo(void *p) { return (int)p; } MSC will respect your decision, while gcc will whine. If you reckon you have to cast anyway, you'd be forced to (int)(size_t)p to get rid of gcc warning. > Works but cast need do be fixed: > cryptlib.c:442: warning: cast from pointer to integer of different size > > printf, should be converted to %p and remove cast: > asn1_lib.c:467: warning: cast from pointer to integer of different size > mem_dbg.c:699: warning: cast from pointer to integer of different size > bio_cb.c:78: warning: cast from pointer to integer of different size > > Should be fixed: > mem_dbg.c:333: warning: cast from pointer to integer of different size > rc4_enc.c:123: warning: cast from pointer to integer of different size > rc4_enc.c:124: warning: cast from pointer to integer of different size > b_print.c:379: warning: cast from pointer to integer of different size > s3_pkt.c:146: warning: cast from pointer to integer of different size > s3_pkt.c:688: warning: cast from pointer to integer of different size > s3_pkt.c:701: warning: cast from pointer to integer of different size This will be addressed in one way or another, but I can't say that I agree with assertion that an interface needs to be changed. I'm not saying that change is not an option! I'm only saying "feel free to elaborate on assertion." A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
On Thursday 30 October 2008, Andy Polyakov via RT wrote: > > There is no assembly support for pe64. > > Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules. > There is no support for GNU assembler under Win64, but masm (rather > known as ml64) and nasm are fully supported (though there are > requirements for least supported versions, for nasm it's 2.03). This would be great! > > I am not fully sure that the crypto/sha/sha512.c is correct, it > > simulate the behavior of win64 using Microsoft compiler, using > > _rotr64 function as ROTR. > > What you should have done instead is to modify macro in question > declaring ret as unsigned long long. If it doesn't work, then it's more > appropriate to leave ROTR undefined, i.e. *not* using _rotr64. Please > verify. Thanks, I converted this to SHA_LONG64 and it now compiles. > Also. As NT is natively UNICODE, and there are no non-NT Win64 > implementations(*), there is no reason to favor legacy ANSI interfaces. > Could you verify that it compiles and works with -DUNICODE -D_UNICODE > added to config line? A. This is too much work, and it is not related to mingw-win64, as this is needed also for NT port. There is too much dependency in ANSI in current implementation. I forgot to mention that the uplink was removed due to assembly issues. There is another issue... sizeof(long)http://www.opensc-project.org/build/browser/trunk/mingw64 [2] http://www.opensc-project.org/build/browser/trunk diff -urNp openssl-SNAP-20081003/Configure openssl-SNAP-20081003.mingw64/Configure --- openssl-SNAP-20081003/Configure 2008-09-16 00:00:05.0 +0300 +++ openssl-SNAP-20081003.mingw64/Configure 2008-10-20 12:37:37.0 +0200 @@ -496,6 +496,8 @@ my %table=( # MinGW "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::MINGW32:-lws2_32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a", +"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -Wall -D_WIN32_WINNT=0x333:::MINGW64:-lws2_32 -lgdi32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${no_asm}:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a", + # UWIN "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", @@ -968,7 +970,7 @@ foreach (sort (keys %disabled)) my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds; -$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target eq "mingw"); +$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target =~ /^mingw/); $exe_ext=".nlm" if ($target =~ /netware/); $exe_ext=".pm" if ($target =~ /vos/); $openssldir="/usr/local/ssl" if ($openssldir eq "" and $prefix eq ""); --- openssl-SNAP-20081003/engines/e_aep.c 2008-01-04 01:01:24.0 +0200 +++ openssl-SNAP-20081003.mingw64/engines/e_aep.c 2008-10-20 12:46:24.0 +0200 @@ -62,8 +62,10 @@ #include #else #include +#ifndef _PID_T_ typedef int pid_t; +#endif #endif #if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_CLIB) #define getpid GetThreadID diff -urNp openssl-SNAP-20081028.org/crypto/sha/sha512.c openssl-SNAP-20081028/crypto/sha/sha512.c --- openssl-SNAP-20081028/crypto/sha/sha512.c 2008-04-24 13:00:12.0 +0300 +++ openssl-SNAP-20081028.mingw64/crypto/sha/sha512.c 2008-10-30 22:41:20.0 +0200 @@ -350,7 +350,7 @@ static const SHA_LONG64 K512[80] = { #ifndef PEDANTIC # if defined(__GNUC__) && __GNUC__>=2 && !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_NO_INLINE_ASM) # if defined(__x86_64) || defined(__x86_64__) -# define ROTR(a,n) ({ unsigned long ret; \ +# define ROTR(a,n) ({ SHA_LONG64 ret; \ asm ("rorq %1,%0" \ : "=r"(ret) \ : "J"(n),"0"(a) \ --- openssl-SNAP-20081028/apps/speed.c 2008-10-30 22:59:03.0 +0200 +++ openssl-SNAP-20081028.mingw64/apps/speed.c 2008-10-30 22:59:16.0 +0200 @@ -281,7 +281,7 @@ static double Time_F(int s) if (thr==NULL) { DWORD ret=GetLastError(); - BIO_printf(bio_err,"unable to CreateThread (%d)",ret); + BIO_printf(bio_err,"unable to CreateThread (%ld)",ret); ExitProcess(ret); } CloseHandle(thr); /* detach the thread */ --- openssl-SNAP-20081028/crypto/jpake/jpake.c 2008-10-27 15:00:14.0 +0200 +++ openssl-SNAP-20081028.mingw64/crypto/jpake/jpake.c 2008-10-30 23:23:30.0 +0200 @@ -5,6 +5,7 @@ #include #include #include +#include /* * In the definition, (xa, xb, xc, xd) are Alice's (x1, x2, x3, x4) or
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
> There is no assembly support for pe64. Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules. There is no support for GNU assembler under Win64, but masm (rather known as ml64) and nasm are fully supported (though there are requirements for least supported versions, for nasm it's 2.03). > So no assembly is available. If assembler was to be added to mingw64, I'd rather deploy nasm. It would be easiest. > Can someone estimate if it is better to use 32bit with assembly than > 64bit without? 64-bit algorithms, most notably SHA512, would perform better with 64-bit compiler, while 32-bit assembler is likely to outperform it on 32-bit algorithms (such as everything else symmetric). Indeed, 32-bit assembler normally delivers ~80% of 64-bit assembler on 32-bit algorithms (not on SHA256 though), so assuming that 64-bit assembler gives at least 30% improvement over 64-bit compiler generated code... As for BN performance. As it is *now*, 32-bit assembler would perform approximately as fast as (if not better) 64-bit compiler generated code, but[!] it's possible to improve the latter. Try following. In bn_lcl.h there is BN_UMULT_HIGH definition in #elif defined(__x86_64) && defined(SIXTY_FOUR_BIT_LONG) in __GNUC__. Replace last defined() with (defined(SIXTY_FOUR_BIT_LONG) || defined(SIXTY_FOUR_BIT)). This will give significant performance improvement. Please verify. > I am not fully sure that the crypto/sha/sha512.c is correct, it > simulate the behavior of win64 using Microsoft compiler, using > _rotr64 function as ROTR. What you should have done instead is to modify macro in question declaring ret as unsigned long long. If it doesn't work, then it's more appropriate to leave ROTR undefined, i.e. *not* using _rotr64. Please verify. Also. As NT is natively UNICODE, and there are no non-NT Win64 implementations(*), there is no reason to favor legacy ANSI interfaces. Could you verify that it compiles and works with -DUNICODE -D_UNICODE added to config line? A. (*) this is unlike Win32, which was available as NT and Win9x, where latter was natively ANSI. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hello, Attached is latest mingw win64 patch for OpenSSL. It is verified to work with the OpenSC project and the OpenVPN project using cross compile from Linux machine using binutils CVS head, gcc-4.3.2 and mingw-w64 svn head. There is no assembly support for pe64. So no assembly is available. Can someone estimate if it is better to use 32bit with assembly than 64bit without? I am not fully sure that the crypto/sha/sha512.c is correct, it simulate the behavior of win64 using Microsoft compiler, using _rotr64 function as ROTR. If correct, please consider to merge this so there is some solution for win64 users and not require to keep syncing with CVS head. I use: ./Configure --prefix="//" --cross-compile-prefix=x86_64-pc-mingw32- no-zlib shared mingw64 no-capieng Thank you, Alon Bar-Lev. diff -urNp openssl-SNAP-20081003/Configure openssl-SNAP-20081003.mingw64/Configure --- openssl-SNAP-20081003/Configure 2008-09-16 00:00:05.0 +0300 +++ openssl-SNAP-20081003.mingw64/Configure 2008-10-20 12:37:37.0 +0200 @@ -496,6 +496,8 @@ my %table=( # MinGW "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::MINGW32:-lws2_32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a", +"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -Wall -D_WIN32_WINNT=0x333:::MINGW64:-lws2_32 -lgdi32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${no_asm}:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a", + # UWIN "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", @@ -968,7 +970,7 @@ foreach (sort (keys %disabled)) my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds; -$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target eq "mingw"); +$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target =~ /^mingw/); $exe_ext=".nlm" if ($target =~ /netware/); $exe_ext=".pm" if ($target =~ /vos/); $openssldir="/usr/local/ssl" if ($openssldir eq "" and $prefix eq ""); --- openssl-SNAP-20081003/engines/e_aep.c 2008-01-04 01:01:24.0 +0200 +++ openssl-SNAP-20081003.mingw64/engines/e_aep.c 2008-10-20 12:46:24.0 +0200 @@ -62,8 +62,10 @@ #include #else #include +#ifndef _PID_T_ typedef int pid_t; +#endif #endif #if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_CLIB) #define getpid GetThreadID --- openssl-SNAP-20081023/crypto/sha/sha512.c 2008-04-24 13:00:12.0 +0300 +++ openssl-SNAP-20081023.mingw64/crypto/sha/sha512.c 2008-10-28 00:19:56.0 +0200 @@ -350,11 +350,15 @@ static const SHA_LONG64 K512[80] = { #ifndef PEDANTIC # if defined(__GNUC__) && __GNUC__>=2 && !defined(OPENSSL_NO_ASM) && !defined(OPENSSL_NO_INLINE_ASM) # if defined(__x86_64) || defined(__x86_64__) -# define ROTR(a,n) ({ unsigned long ret; \ +# if defined(_WIN64) +#define ROTR(a,n) _rotr64((a),n) /* applies to both IA-64 and AMD64 */ +# else +#define ROTR(a,n) ({ unsigned long ret; \ asm ("rorq %1,%0" \ : "=r"(ret) \ : "J"(n),"0"(a) \ : "cc"); ret; }) +# endif # if !defined(B_ENDIAN) #define PULL64(x) ({ SHA_LONG64 ret=*((const SHA_LONG64 *)(&(x))); \ asm ("bswapq %0" \
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
The alarm() will be removed: https://sourceforge.net/tracker/index.php?func=detail&aid=2182468&group_id=202880&atid=983354 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hello, Attached is a new version, against latest snapshot. I don't know how the -DOPENSSL_USE_APPLINK works for you guys... It produces invalid asm for me... I don't fully understand what this file do... perl ../ms/uplink.pl coff > uplink-cof.s x86_64-pc-mingw32-gcc -I. -I.. -I../include -D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_WIN32 -mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -Wall -D_WIN32_WINNT=0x333 -c -o uplink-cof.o uplink-cof.s uplink-cof.s: Assembler messages: uplink-cof.s:5: Error: suffix or operands invalid for `push' uplink-cof.s:6: Error: suffix or operands invalid for `push' uplink-cof.s:13: Error: suffix or operands invalid for `push' WIN32_LEAN_AND_MEAN should also be added to regular mingw target. --- diff -urNp openssl-SNAP-20081003/apps/speed.c openssl-SNAP-20081003.mingw64/apps/speed.c --- openssl-SNAP-20081003/apps/speed.c 2007-11-16 17:00:11.0 +0200 +++ openssl-SNAP-20081003.mingw64/apps/speed.c 2008-10-20 12:58:43.0 +0200 @@ -261,7 +261,8 @@ static SIGRETTYPE sig_done(int sig) #define SIGALRM static unsigned int lapse,schlock; -static void alarm(unsigned int secs) { lapse = secs*1000; } +static void myalarm(unsigned int secs) { lapse = secs*1000; } +#define ALARM myalarm static DWORD WINAPI sleepy(VOID *arg) { @@ -291,6 +291,7 @@ static double Time_F(int s) return app_tminterval(s,usertime); } #else +#define ALARM alarm static double Time_F(int s) { @@ -2514,7 +2515,7 @@ static void print_message(const char *s, BIO_printf(bio_err,mr ? "+DT:%s:%d:%d\n" : "Doing %s for %ds on %d size blocks: ",s,SECONDS,length); (void)BIO_flush(bio_err); - alarm(SECONDS); + ALARM(SECONDS); #else BIO_printf(bio_err,mr ? "+DN:%s:%ld:%d\n" : "Doing %s %ld times on %d size blocks: ",s,num,length); @@ -2532,7 +2533,7 @@ static void pkey_print_message(const cha BIO_printf(bio_err,mr ? "+DTP:%d:%s:%s:%d\n" : "Doing %d bit %s %s's for %ds: ",bits,str,str2,tm); (void)BIO_flush(bio_err); - alarm(RSA_SECONDS); + ALARM(RSA_SECONDS); #else BIO_printf(bio_err,mr ? "+DNP:%ld:%d:%s:%s\n" : "Doing %ld %d bit %s %s's: ",num,bits,str,str2); diff -urNp openssl-SNAP-20081003/Configure openssl-SNAP-20081003.mingw64/Configure --- openssl-SNAP-20081003/Configure 2008-09-16 00:00:05.0 +0300 +++ openssl-SNAP-20081003.mingw64/Configure 2008-10-20 12:37:37.0 +0200 @@ -496,6 +496,8 @@ my %table=( # MinGW "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::MINGW32:-lws2_32 -lgdi32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a", +"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -Wall -D_WIN32_WINNT=0x333:::MINGW64:-lws2_32 -lgdi32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${no_asm}:win32:cygwin-shared:-D_WINDLL:-mno-cygwin -shared:.dll.a", + # UWIN "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", @@ -968,7 +970,7 @@ foreach (sort (keys %disabled)) my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds; -$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target eq "mingw"); +$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target =~ /^mingw*/); $exe_ext=".nlm" if ($target =~ /netware/); $exe_ext=".pm" if ($target =~ /vos/); $openssldir="/usr/local/ssl" if ($openssldir eq "" and $prefix eq ""); --- openssl-SNAP-20081003/engines/e_aep.c 2008-01-04 01:01:24.0 +0200 +++ openssl-SNAP-20081003.mingw64/engines/e_aep.c 2008-10-20 12:46:24.0 +0200 @@ -62,8 +62,10 @@ #include #else #include +#ifndef _PID_T_ typedef int pid_t; +#endif #endif #if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_CLIB) #define getpid GetThreadID __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Ger Hobbelt wrote: On Tue, Jun 3, 2008 at 12:32 PM, [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]> wrote: - windows.h apparently includes wincrypt.h (no idea whether that's specific to that compiler, but it seems so ...), so I needed to #undefine a couple of names messed up by wincrypt.h (patches to rand.h, x509.h and e_os.h). Same applies when you compile OpenSSL with Microsoft Visual C++ (MSVC6/2003/2005/2008): windows.h / winsock[2].h / wincrypt.h are system header files by Microsoft and wincrypt.h indeed contains several items which [still] conflict with OpenSSL (0.9.9.latest CVS). BTW: I do not use the OpenSSL provided makefiles but MSVC project files to build DLLs and static libs; the *LEAN_AND_MEAN #define is not needed to make OpenSSL compile and behave well. What was necessary however (at least in my case) is making darn sure those windows.h / winsock2.h header files come in before anything 'else' ('else' == standard POSIX header files such as stdlib.h and OpenSSL header files/code, or you'd get a conflict with winsock.h and winsock2.h header files in some cases). Sure and "*LEAN_AND_MEAN #define" resolve this - reference search for "Creating a Basic Winsock Application". In addition this define resolve conflict with recent "wincrypt.h". I can produce diffs if you want them. Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
On Tue, Jun 3, 2008 at 12:32 PM, [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]> wrote: > - windows.h apparently includes wincrypt.h (no idea whether that's > specific to that compiler, but it seems so ...), so I needed to > #undefine a couple of names messed up by wincrypt.h > (patches to rand.h, x509.h and e_os.h). Same applies when you compile OpenSSL with Microsoft Visual C++ (MSVC6/2003/2005/2008): windows.h / winsock[2].h / wincrypt.h are system header files by Microsoft and wincrypt.h indeed contains several items which [still] conflict with OpenSSL (0.9.9.latest CVS). BTW: I do not use the OpenSSL provided makefiles but MSVC project files to build DLLs and static libs; the *LEAN_AND_MEAN #define is not needed to make OpenSSL compile and behave well. What was necessary however (at least in my case) is making darn sure those windows.h / winsock2.h header files come in before anything 'else' ('else' == standard POSIX header files such as stdlib.h and OpenSSL header files/code, or you'd get a conflict with winsock.h and winsock2.h header files in some cases). I can produce diffs if you want them. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
>> How do we know that these are not or should not be treated as mingw64 >> bugs? I mean it worked for mingw for years (I wonder how by the way), >> now ancestor is *being developed* and how come it's not its fault:-) > > I don't really understand that part about "ancestor", but never mind ... Oops! I meant "descendant," i.e. "next derived version":-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Andy Polyakov wrote: > How do we know that these are not or should not be treated as mingw64 > bugs? I mean it worked for mingw for years (I wonder how by the way), > now ancestor is *being developed* and how come it's not its fault:-) I don't really understand that part about "ancestor", but never mind ... > Well, I can accept that pid_t could be treated better in OpenSSL (#ifdef > there is nothing but strange), but I don't buy masking of alarm. It's > impossible to implement Unix-ish alarm on Windows and it simply > shouldn't be there (nor SIGALRM definition). Quick check reveals that > alarm is nothing but "return 0." What's more appropriate: to be honest > or not to tell truth? I mean absence of alarm would be honest, while > implementing it as return 0 would be "not telling truth"... Sounds convincing to me, so I took the liberty to forward this to the mingw-w64 mailing list in the hope that they'll do something about it. Thanks, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
> Here's a patch against today's snapshot of head. > >>> I think that you has to compile with -DWIN32_LEAN_AND_MEAN in >>> Configure before to do some undefs in openssl headers. > > I'm not really convinced, but for the time being, I've added that > compile > option to get rid of that more or less cosmetic issue. > Apart from adding a line to configure, I needed a slight modification > to apps/speed.c and engines/e_aep.c because mingw-w64 comes > with definitions for "pid_t" and "alarm" How do we know that these are not or should not be treated as mingw64 bugs? I mean it worked for mingw for years (I wonder how by the way), now ancestor is *being developed* and how come it's not its fault:-) Well, I can accept that pid_t could be treated better in OpenSSL (#ifdef there is nothing but strange), but I don't buy masking of alarm. It's impossible to implement Unix-ish alarm on Windows and it simply shouldn't be there (nor SIGALRM definition). Quick check reveals that alarm is nothing but "return 0." What's more appropriate: to be honest or not to tell truth? I mean absence of alarm would be honest, while implementing it as return 0 would be "not telling truth"... > and in crypto/mem_cmp.c, http://cvs.openssl.org/chngview?cn=17337. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi, > > Please, could you propose a patch to the OpenSSL head. > > In the head -lwsock32 is replaced by -lws2_32. Here's a patch against today's snapshot of head. > > I think that you has to compile with -DWIN32_LEAN_AND_MEAN in > > Configure before to do some undefs in openssl headers. I'm not really convinced, but for the time being, I've added that compile option to get rid of that more or less cosmetic issue. Apart from adding a line to configure, I needed a slight modification to apps/speed.c and engines/e_aep.c because mingw-w64 comes with definitions for "pid_t" and "alarm" and in crypto/mem_cmp.c, gcc complained about a (and b) being redefined as a different kind of symbol, so I renamed the local symbols to have different names from the parameters. Regards, Stefan openssl-HEAD.patch Description: Binary data
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi, > Please, could you propose a patch to the OpenSSL head. > In the head -lwsock32 is replaced by -lws2_32. Will do.. > I think that you has to compile with -DWIN32_LEAN_AND_MEAN in Configure > before to do some undefs in openssl headers. Also see other win64 targets. But doesn't that mean that any user of openssl wanting to use e.g. X509_EXTENSIONS has to take care of that problem himself? Also, x509.h is already undefining 2 of the 3 problematic symbols anyway. IMO that's something that really should be "fixed" in the headers. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi Stefan, [EMAIL PROTECTED] via RT wrote: Hi, I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see http://sourceforge.net/projects/mingw-w64/) and needed a couple of changes to the source code (see attached patch). Some notes: - I added a "mingw64" line to Configure and (think I) told it to use .exe extension for compiling. Nothing surprising here, I think. Note that you currently need to "Configure mingw64 no-asm no-hw". [SNIP] Please, could you propose a patch to the OpenSSL head. In the head -lwsock32 is replaced by -lws2_32. I think that you has to compile with -DWIN32_LEAN_AND_MEAN in Configure before to do some undefs in openssl headers. Also see other win64 targets. Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1693] Compiling OpenSSL with mingw-w64
Hi, I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see http://sourceforge.net/projects/mingw-w64/) and needed a couple of changes to the source code (see attached patch). Some notes: - I added a "mingw64" line to Configure and (think I) told it to use .exe extension for compiling. Nothing surprising here, I think. Note that you currently need to "Configure mingw64 no-asm no-hw". - windows.h apparently includes wincrypt.h (no idea whether that's specific to that compiler, but it seems so ...), so I needed to #undefine a couple of names messed up by wincrypt.h (patches to rand.h, x509.h and e_os.h). - It's using a very recent snapshot of gcc, so there also is the problem in e_os2.h, that has already been reported for gcc-4.3: the compiler complains about the same variable being declared as both extern and static - so I changed that to use static both times - but I'm not really sure what's the correct thing to do here. Regards, Stefan openssl-h.patch Description: Binary data