It is indeed the quoting of the perl command interpreter issue. I also work often on *nix platforms, and tested with \"$^X\", which worked. But I can’t guarantee that too for all *nix flavors... It may be worth trying it (unless someone else complains). If you are unsure for a certain *nix flavor, please let me know. We may have that platform in house (currently, our product is built on Suse Linux, HPUX (PA-risc + Itanium), Solaris, AIX, Windows. Secondary platforms: Tru64. Our product also run on RedHat linux (although we built on Suse SLES 10)).
Kees -----Original Message----- From: Andy Polyakov via RT [mailto:[email protected]] Sent: Tuesday, June 26, 2012 17:10 To: Kees Dekker Cc: [email protected] Subject: Re: [openssl.org #2835] question/proposal for openssl 1.0.1c to make do_ms.bat and do_win64a.bat somewhat more consisent + solve build errors for WIN64a. > As answer on your question whether ml64.exe is existent: when setting > Visual Studio 2010 (SP1) x64 command line environment, ml64.exe is > accessible via the path (in c:\Program Files (x86)\Microsoft Visual > Studio 10.0\VC\bin\amd64\ml64.exe). Just for the record. Even if ml64 is not unsupported, it's still "when in doubt use nasm" policy that is in effect. Anyway, if ml64 is present on %PATH%, then how come "since I did not have nasm installed, the build for 32-bit succeeded, but for 64-bit not"? Or is it $^X vs. \"$^X\" in ms\uplink-x86_64.pl issue rather than availability of nasm or ml64 after all? Bottom line. \"$^X\" in ms\uplink-x86_64.pl is absolute minimal requirement for cases when Perl is installed in directory with spaces. I'm a bit reluctant to propagate this on all modules, because there is no guarantee that it won't cause problems on *any other* supported platform. It shouldn't, but there is no way of actually be sure. I'd rather simply require that Perl is available on path without spaces. One can create a junction is worst case... :��I"Ϯ��r�m���� (����Z+�7�zZ)���1���x ��h����W^��^��%�� ��&jם.+-1�ځ��j:+v�������h�
