Also from win32's asm build, all of the script invocations forgot to
include the nasm/masm(ml64) command line arg...
What does it mean exactly?
I'll get you a patch shortly, but in short, it meant that do_amd64
was emitting an ntdll.mak line to invoke sha1-x86_64.pl but didn't
add the nasm
http://rt.openssl.org/Ticket/Display.html?id=2435user=guestpass=guest
http://rt.openssl.org/Ticket/Display.html?id=2440user=guestpass=guest
Are there plans to revisit this before 1.0.1 GA, and is anyone working
on this broken schema? It seems the GA would be a great time to get
this right.
Also
On 3/9/2012 1:45 PM, William A. Rowe Jr. wrote:
http://rt.openssl.org/Ticket/Display.html?id=2435user=guestpass=guest
http://rt.openssl.org/Ticket/Display.html?id=2440user=guestpass=guest
Simpler is usually better... what specific behavior is the deleted code
below trying to accomplish? Is
http://rt.openssl.org/Ticket/Display.html?id=2435user=guestpass=guest
http://rt.openssl.org/Ticket/Display.html?id=2440user=guestpass=guest
Simpler is usually better... what specific behavior is the deleted code
below trying to accomplish?
Correct question is not what stat-ing *is* trying
Also from win32's asm build, all of the script invocations forgot to
include the nasm/masm(ml64) command line arg...
What does it mean exactly?
the entire windows build
doesn't appear to be very deterministic in terms of picking an assembler
and sticking to it.
Assembler is picked at
On 3/9/2012 4:55 PM, Andy Polyakov wrote:
Also from win32's asm build, all of the script invocations forgot to
include the nasm/masm(ml64) command line arg...
What does it mean exactly?
I'll get you a patch shortly, but in short, it meant that do_amd64
was emitting an ntdll.mak line to
