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
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
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
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 alg. 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 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
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
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
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)sizeof(void*) in win64... So I found
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 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 unistd.h
#else
#include process.h
+#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 process.h
+# include tchar.h
#elif defined(OPENSSL_SYS_VMS)
# include opcdef.h
# include descrip.h
@@ -253,7 +252,7 @@ static void xopenlog(BIO* bp,
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 unistd.h
#else
#include process.h
+#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
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
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)sizeof(void*) in win64... So I found
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. I just don't understand how using Microsoft compiler this
code makes
sense.
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
dllimport issues, probably unrelated:
ecb_enc.c:64: warning: ‘OSSL_libdes_version’ redeclared without
dllimport attribute: previous dllimport ignored
ecb_enc.c:65: warning: ‘OSSL_DES_version’ redeclared without dllimport
attribute: previous dllimport ignored
s2_lib.c:124: warning: ‘ssl2_ciphers’ redeclared without dllimport
attribute: previous dllimport ignored
s3_lib.c:170: warning: ‘ssl3_ciphers’ redeclared without dllimport
attribute: previous dllimport ignored
If you like, I wrote a build script for the mingw-win64 toolchain and OpenSC
components (Including OpenSSL).
It is available at [1] and [2].
Attached is a new patch.
Thank you,
Alon Bar-Lev.
[1] 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 unistd.h
#else
#include
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'
snip
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 unistd.h
#else
#include process.h
+#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
The alarm() will be removed: https://sourceforge.net/tracker/index.php?func=detailaid=2182468group_id=202880atid=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
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
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
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
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
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. 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, 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 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]
