In my experience this is your copy of Perl itself not being
compatible with your remote execution system.
Try adding these 6 commands before the first Perl call to
confirm this:
del hello1.txt
del hello2.txt
del hello3.txt
echo Hello > hello1.txt
call perl -e "print qq!Hello\n!" > hello2.txt
echo Hello > hello3.txt
If your Perl is OK in the execution environment, you should
be left with 3 files all saying "Hello\r\n".
If your Perl is Bad in the execution environment, you should
get good hello1.txt and hello3.txt, but bad hello2.txt.
If your Perl is very Bad in the execution environment, you
should get good hello1.txt, bad hello2.txt and no hello3.txt.
Other results will need further investigation.
P.S.
I have not tested these steps, I just typed them into the e-mail.
On 2/1/2012 5:18 PM, Eric Lordahl wrote:
I have openSSL set up as a dependency for other projects that I’m
building. It builds with the following commands:
call perl Configure VC-WIN64A no-zlib no-shared --prefix=.
call ms\do_win64a
nmake -f ms\nt.mak
This works fine, but only if I’m physically at the command prompt. If
I attempt to redirect the output to a file, the build fails. The error
is due to crypto/x86_64cpuid.pl. It looks like it’s trying to create a
file, but the file doesn’t get generated, so when that file is
referenced it throws an error. In line 11 of this file it attempts to
open STDOUT, so I’m thinking that the redirection of the console log
is causing this line to break, and the file to not get generated.
Anyone else run into this and have a workaround?
*Eric Lordahl *
MANDIANT
Software Engineer
2318 Mill Road
Suite 500
Alexandria, VA 22314
703.224.2976 t
703.683.2891 f
703.615.8793 m
eric.lord...@mandiant.com <mailto:eric.lord...@mandiant.com>
www.mandiant.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
