Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
On 10/31/08, Andy Polyakov via RT <firstname.lastname@example.org> wrote:[color=blue]
> Could you please test the other suggested bn_lcl.h modification? While
> you're on it...[/color]
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.[/color]
> > Thanks, I converted this to SHA_LONG64 and it now compiles.[/color]
> Can you confirm that it even passes the test? I mean mere compilation
> success doesn't qualify, it has to pass the test.[/color]
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?[/color]
> > This is too much work,[/color]
> Adding couple of words to config line?[/color]
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.[/color]
Well... I don't run this script :)
Attached is a new patch.