Re: {hash}-x86_64.pl assembly scripts just too fragile
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 or masm arg. And it shouldn't have. The assembler is passed not by argument, but by environment variable, 'set ASM=$(ASM)' in perl-asm rules. Should, but didn't, I'll work on the patch, Let's figure out why exactly it didn't work first. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
{hash}-x86_64.pl assembly scripts just too fragile
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 from win32's asm build, all of the script invocations forgot to include the nasm/masm(ml64) command line arg... the entire windows build doesn't appear to be very deterministic in terms of picking an assembler and sticking to it. I'd work on this, but from these 15 month old tickets I don't have much confidence in any patches being adopted. If we beta testers invest some time in trashing the ugliness, is there a committer who would commit to reviewing and committing fixes? I'd love to avoid a fork on this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: {hash}-x86_64.pl assembly scripts just too fragile
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 there something more needed here, and does
that need to be done in the currently contorted fashion?
Index: crypto/perlasm/x86_64-xlate.pl
===
--- crypto/perlasm/x86_64-xlate.pl (revision 6904)
+++ crypto/perlasm/x86_64-xlate.pl (working copy)
@@ -62,13 +62,9 @@
my $output = shift;
if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
-{ my ($stddev,$stdino,@junk)=stat(STDOUT);
- my ($outdev,$outino,@junk)=stat($output);
+open STDOUT,$output || die can't open $output: $!
+if (defined($output));
-open STDOUT,$output || die can't open $output: $!
- if ($stddev!=$outdev || $stdino!=$outino);
-}
-
my $gas=1; $gas=0 if ($output =~ /\.asm$/);
my $elf=1; $elf=0 if (!$gas);
my $win64=0;
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: {hash}-x86_64.pl assembly scripts just too fragile
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 to accomplish, but
what it *was* trying to accomplish. It *was* required at some point to
compile x86_64cpuid.pl, but it shouldn't be anymore... I'll cross-check
and remove it this weekend.
Index: crypto/perlasm/x86_64-xlate.pl
===
--- crypto/perlasm/x86_64-xlate.pl (revision 6904)
+++ crypto/perlasm/x86_64-xlate.pl (working copy)
@@ -62,13 +62,9 @@
my $output = shift;
if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
-{ my ($stddev,$stdino,@junk)=stat(STDOUT);
- my ($outdev,$outino,@junk)=stat($output);
+open STDOUT,$output || die can't open $output: $!
+if (defined($output));
-open STDOUT,$output || die can't open $output: $!
- if ($stddev!=$outdev || $stdino!=$outino);
-}
-
my $gas=1; $gas=0 if ($output =~ /\.asm$/);
my $elf=1; $elf=0 if (!$gas);
my $win64=0;
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: {hash}-x86_64.pl assembly scripts just too fragile
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 ./Configure time giving preference to nasm. As long as you have it on %PATH% at all times, you should be fine. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: {hash}-x86_64.pl assembly scripts just too fragile
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 invoke sha1-x86_64.pl but didn't add the nasm or masm arg. 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 ./Configure time giving preference to nasm. As long as you have it on %PATH% at all times, you should be fine. Should, but didn't, I'll work on the patch, thanks for looking at the first issue already. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
