----- Original Message -----
From: "Stephen Bennett" <sbenn...@accelrys.com>
To: "Sisyphus" <sisyph...@optusnet.com.au>; <bug-win32-...@rt.cpan.org>
Cc: <libwin32@perl.org>
Sent: Tuesday, April 27, 2010 8:01 AM
Subject: RE: [rt.cpan.org #55660] [PATCH] Partial win64 support for
Win32::API
Apologies for the delayed reply -- I was rather busy at the time and then
subsequently just forgot about this.
###############################
Test Summary Report
-------------------
t/00_API.t (Wstat: 1280 Tests: 11 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 25 tests but ran 11.
t/01_Struct.t (Wstat: 1280 Tests: 5 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 7 tests but ran 5.
Files=6, Tests=53, 19 wallclock secs ( 0.17 usr + 0.11 sys = 0.28 CPU)
Result: FAIL
Failed 2/6 test programs. 0/53 subtests failed.
NMAKE : fatal error U1077: 'C:\_64\perl1007\bin\perl.exe' : return code
'0xff'
Stop.
###############################
Is that as anticipated ?
No; the Win32::API tests should pass (and do on my build). Can you find
out which tests exactly are failing? That looks somewhat like the
testsuite is crashing perl; in which test?
It's test 12 that crashes. When I clear the pop-up the test script aborts -
no more tests get run in that script.
Here's the output:
C:\cygwin\home\Rob\GIT\win32-api>perl -Mblib t/00_API.t
1..25
ok 1 - use Win32::API;
ok 2 - use Win32::API::Test;
ok 3 - use Win32;
ok 4 - loaded
# API test dll found at (API_test64.dll)
ok 5 - found API test dll
ok 6 - GetCurrentProcessId() function found
ok 7 - GetCurrentProcessId() result ok
ok 8 - GetCurrentProcessId() result ok
ok 9 - Import of GetCurrentProcessId() function from kernel32.dll
ok 10 - GetCurrentProcessId() result ok
ok 11 - sum_integers() function defined
It's the '$function->Call(2, 3)' that causes the crash - which I guess means
that the dll being accessed ("our own DLL") is not to my compiler's liking.
Now ... to try and find out why ml.exe is being called, instead of
ml64.exe.
That sounds like your environment is set up for the 32-bit MSVC++
toolchain, instead of the x64 one. Assuming you're using the vcvars batch
file to set up your environment for NMAKE, are you giving it the right
arguments for an x64 build?
I'm using the Microsoft Platform SDK for Windows Server 2003 R2 compiler
(same as ActiveState use to build x64 ActivePerl) and, to set up the
environment I run:
SetEnv.cmd /XP64 /RETAIL
That's the correct thing to do, afaik, and I've been getting good mileage
out of it.
I notice, however, that 'nmake /P' lists:
AS = ml
instead of the expected 'AS = ml64' - so, I guess either it's a bug in
nmake, or it's an nmake that expects a 32-bit environment. (I've checked,
and there's no 'nmake64.exe' or anything like that.)
As a fix, I've simply created a copy of ml64.exe named ml.exe in the same
folder. (The 32-bit ml.exe is in a folder that's not in my path.)
Cheers,
Rob
