On Tue, May 21, 2013 at 10:14:27AM -0600, Phillip Hellewell wrote:
> Good news, I found the bug! I got thinking, why is x86_64-gf2m the
> only one giving me a problem? So I compared x86_64-gf2m.pl to the
> others and found that it has this line:
> open STDOUT,"| \"$^X\" $xlate $flavour $output";
> whereas the others have this:
> open OUT,"| \"$^X\" $xlate $flavour $output";
> *STDOUT=*OUT;
>
> I don't know perl well enough to understand the distinction between
> these, but it is obviously important to use the latter :)
A Windows specific Perl issue:
https://rt.openssl.org/Ticket/Display.html?id=2963&user=guest&pass=guest
http://old.nabble.com/nasm-intermittently-fails-to-assemble-a-file-td29947144.html
Most likely Perl's close() behaves differently on Windows for the
real STDOUT and does not wait for the child process if the STDOUT
file descriptor a pipe. Reassigning STDOUT likely removes the
magic treatment.
If so, this is a Windows Perl bug IMHO. The parent should wait
for the child to exit with close(STDOUT) in either scenario.
Any special treatment of STDOUT should be reset after
open STDOUT,"|cmd";
in such a way as to ensure that wait() happens on close().
I've not had to jump through hoops like that using Perl on Unix
since Perl 0.9. And while making Windows look like Unix is not
easy, one should not have to do this on Windows either.
Does anyone know whether this issue has been reported to the Perl
maintainers (and perhaps fixed in some sufficiently recent release)?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
