Steve.Hay at verosoftware
Aug 3, 2012, 12:55 AM
Post #10 of 11
Sisyphus wrote on 2012-08-02:
> ----- Original Message -----
> From: "Steve Hay"
>>> Anyway if, instead of editing the makefile.mk, I run (as you did):
>>> dmake WIN64=define GCCCROSS=define
>>> I get the same problem as you reported: "This is perl 5, version
>>> 17, subversion 3 (v5.17.3) built for MSWin32- x86-multi-thread"
>>> That's using my x64 4.7.0 cross-compiler (automated build). So ....
>>> passing args from the command line isn't working as intended ....
>> I tried building the same way as you (no WIN64 defined in the
>> environment or on the command-line) and still get the wrong archname.
>> Now I'm puzzled why yours goes wrong when you specify WIN64=define on
>> the command-line. I can see that that stops it going into the section
>> which sets up WIN64 if it is not set, but PROCESSOR_ARCHITECTURE should
>> still have been imported (in your case, correctly), just the same...
> If this hasn't been resolved by the time I get back home on Monday I'll
> see if I can come up with something that's in some way helpful ;-)
I must have screwed up my attempt to build with no WIN64 defined anywhere, because I've just tried again and it does indeed work, as you say.
The makefile.mk below reproduces the problem. If you run dmake with no WIN64 defined anywhere then it indeed outputs MSWin32-x64, but if you define WIN64 anywhere at all (in the environment which it imports, or on the command-line, or by editing the makefile.mk), and to any value at all (undef, define, or anything else), then it outputs MSWin32-x86!
It happens because if WIN64 is set to anything by any means then it skips the bit which forcibly overrides the imported PROCESSOR_ARCHITECTURE value with the imported PROCESSOR_ARCHITEW6432 value (if present), but that's the bit which turns the unexpected x86 back to the expected AMD64...
That tripped me up because I have WIN64=undef set in my environment since I'm running on 64-bit (and using the 64-bit cmd.exe), but generally building a 32-bit perl. As kmx pointed out, that's the (only!) documented use of the WIN64 macro, but I was then specifying WIN64=define on the command-line when I actually wanted a 64-bit build, naively thinking that that would undo the WIN64=undef in the environment and thus get me a 64-bit build.
So, user error on my part, but it's not a friendly interface at all, and I'm now agreeing very much with kmx's suggestion earlier in this thread of revamping how a user specifies whether to build 32-bit or 64-build etc...
#WIN64 *= undef
.IMPORT .IGNORE : PROCESSOR_ARCHITECTURE PROCESSOR_ARCHITEW6432 WIN64
PROCESSOR_ARCHITECTURE *= x86
.IF "$(WIN64)" == ""
.IF "$(PROCESSOR_ARCHITEW6432)" != ""
PROCESSOR_ARCHITECTURE != $(PROCESSOR_ARCHITEW6432)
WIN64 = define
.ELIF "$(PROCESSOR_ARCHITECTURE)" == "AMD64"
WIN64 = define
WIN64 = undef
ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
.IF "$(ARCHITECTURE)" == "AMD64"
ARCHITECTURE = x64
ARCHNAME = MSWin32-$(ARCHITECTURE)