Mailing List Archive: Perl: porters

WIN64 builds with dmake

Index | Next | Previous | View Threaded

steve.m.hay at googlemail

Aug 1, 2012, 1:49 PM

Post #1 of 11 (161 views)
Permalink

WIN64 builds with dmake

In the course of testing the new USE_64_BIT_INT option which
1f64ae1564 added to the Windows makefiles, I found that there are
(existing) problems with doing a full 64-bit build (WIN64=define) when
using dmake / makefile.mk.

The problem is that dmake.exe is a 32-bit program, so it only sees the
WOW6432 environment, even when running in the 64-bit cmd.exe. It
therefore ends up seeing that PROCESSOR_ARCHITECTURE is x86 rather
than AMD64 (and PROCESSOR_ARCHITEW6432 is also defined (set to
AMD64)), and hence ARCHITECTURE gets wrongly set to x86 rather than
x64.

For MinGW-w64 this seems to succeed, producing a full 64-bit build,
but with archname wrongly set to MSWin32-x86... rather than
MSWin32-x64...

But for VC++ it results in LINK_FLAGS specifying -machine:x86 instead
of the required -machine:x64 and the build fails very early on.

Normally, of course, one uses nmake / Makefile for VC++ builds, and
with the x64 tools nmake.exe is 64-bit itself so it sees the correct
PROCESSOR_ARCHITECTURE value and the problem doesn't occur.

Is there any way around this (other than the obvious fix of building a
64-bit dmake.exe)?

sisyphus1 at optusnet

Aug 1, 2012, 7:20 PM

Post #2 of 11 (156 views)
Permalink

Re: WIN64 builds with dmake [In reply to]

----- Original Message -----
From: "Steve Hay" <steve.m.hay [at] googlemail>
To: <perl5-porters [at] perl>
Sent: Thursday, August 02, 2012 6:49 AM
Subject: WIN64 builds with dmake

> In the course of testing the new USE_64_BIT_INT option which
> 1f64ae1564 added to the Windows makefiles, I found that there are
> (existing) problems with doing a full 64-bit build (WIN64=define) when
> using dmake / makefile.mk.
>
> The problem is that dmake.exe is a 32-bit program, so it only sees the
> WOW6432 environment, even when running in the 64-bit cmd.exe. It
> therefore ends up seeing that PROCESSOR_ARCHITECTURE is x86 rather
> than AMD64 (and PROCESSOR_ARCHITEW6432 is also defined (set to
> AMD64)), and hence ARCHITECTURE gets wrongly set to x86 rather than
> x64.
>
> For MinGW-w64 this seems to succeed, producing a full 64-bit build,
> but with archname wrongly set to MSWin32-x86... rather than
> MSWin32-x64...

It used to (up until as recent as 5.17.1, at least) set the archname
correctly to MSWin32-x64....

So something must have changed ... or you might have inadvertently set WIN64
= undef near the top of the makefile.mk.

I've just built current bleadperl with 32-bit dmake and 64-bit mingw64
compiler.
Archname was set correctly for me.

Cheers,
Rob

kmx at atlas

Aug 2, 2012, 12:06 AM

Post #3 of 11 (153 views)
Permalink

Re: WIN64 builds with dmake [In reply to]

On 1.8.2012 22:49, Steve Hay wrote:
> In the course of testing the new USE_64_BIT_INT option which
> 1f64ae1564 added to the Windows makefiles, I found that there are
> (existing) problems with doing a full 64-bit build (WIN64=define) when
> using dmake / makefile.mk.
>
> The problem is that dmake.exe is a 32-bit program, so it only sees the
> WOW6432 environment, even when running in the 64-bit cmd.exe. It
> therefore ends up seeing that PROCESSOR_ARCHITECTURE is x86 rather
> than AMD64 (and PROCESSOR_ARCHITEW6432 is also defined (set to
> AMD64)), and hence ARCHITECTURE gets wrongly set to x86 rather than
> x64.

Before a discussion about improving auto-detection It'll be nice to have an
explicit option by which I can tell that I want 32/64bit build.

I know, we have WIN64=... but it is intended only for (quote):
"if you want to build a 32-bit Perl using a 32-bit compiler on a 64-bit
version of Windows"

Although you can use:
1/ dmake ... WIN64=define (for 64bit build)
2/ dmake ... WIN64=undef (for 32bit build)
the makefile's comment does not declare WIN64 variable as "target
architecture switch"

I would like more to turn WIN64 into something more obvious allowing to say
"go for 32bit build" or "go for 64bit build" without any additional
auto-detection. So something like:

dmake ... TARGET=WIN64 vs. dmake ... TARGET=WIN32
or
dmake ... TARGET=x64 vs. dmake ... TARGET=x86

As for the auto-detection the question is - what is the key fact we want to
based autodetection on:
a/ platform we are running the build process on?
b/ compiler's target architecture which can differ from a/? (BUT we have
cross-compilers; gcc[multilib] can support both 32/64bit targets at once)

Now we are using approach a/ as it is possible to make it by inspecting
PROCESSOR_ARCHITECTURE* variables. I feel that using approach b/ would be
slightly better; however I have no idea how to make this kind of detection
inside makefile.

It is IMHO not necessary to make auto-detection more complicated, however
the build should "loudly" fail as soon as possible when there is a mismatch
between wanted perl architecture and compiler target architecture.

> For MinGW-w64 this seems to succeed, producing a full 64-bit build,
> but with archname wrongly set to MSWin32-x86... rather than
> MSWin32-x64...

I remember the same troubles some time ago.

In 64bit strawberry perl build process (runs from 32bit environment) we
explicitly override (ugly, I know) env variable
PROCESSOR_ARCHITECTURE=AMD64 before launching 32bit dmake.

> But for VC++ it results in LINK_FLAGS specifying -machine:x86 instead
> of the required -machine:x64 and the build fails very early on.
>
> Normally, of course, one uses nmake / Makefile for VC++ builds, and
> with the x64 tools nmake.exe is 64-bit itself so it sees the correct
> PROCESSOR_ARCHITECTURE value and the problem doesn't occur.
>
> Is there any way around this (other than the obvious fix of building a
> 64-bit dmake.exe)?

Just a note: 64bit dmake.exe used is available at:
http://strawberryperl.com/package/kmx/64_tools/

--
kmx

Steve.Hay at verosoftware

Aug 2, 2012, 3:24 AM

Post #4 of 11 (153 views)
Permalink

RE: WIN64 builds with dmake [In reply to]

Sisyphus wrote on 2012-08-02:
>
> ----- Original Message -----
> From: "Steve Hay" <steve.m.hay [at] googlemail>
> To: <perl5-porters [at] perl>
> Sent: Thursday, August 02, 2012 6:49 AM
> Subject: WIN64 builds with dmake
>
>
>> In the course of testing the new USE_64_BIT_INT option which 1f64ae1564
>> added to the Windows makefiles, I found that there are (existing)
>> problems with doing a full 64-bit build (WIN64=define) when using dmake
>> / makefile.mk.
>>
>> The problem is that dmake.exe is a 32-bit program, so it only sees the
>> WOW6432 environment, even when running in the 64-bit cmd.exe. It
>> therefore ends up seeing that PROCESSOR_ARCHITECTURE is x86 rather than
>> AMD64 (and PROCESSOR_ARCHITEW6432 is also defined (set to AMD64)), and
>> hence ARCHITECTURE gets wrongly set to x86 rather than x64.
>>
>> For MinGW-w64 this seems to succeed, producing a full 64-bit build,
>> but with archname wrongly set to MSWin32-x86... rather than
>> MSWin32-x64...
>
> It used to (up until as recent as 5.17.1, at least) set the archname
> correctly to MSWin32-x64....
>
> So something must have changed ... or you might have inadvertently set
> WIN64 = undef near the top of the makefile.mk.
>
> I've just built current bleadperl with 32-bit dmake and 64-bit mingw64
> compiler. Archname was set correctly for me.

That's odd.

What OS are you on (specifically, 32-bit or 64-bit)? If you're on a 64-bit OS then what cmd.exe are you using (the 64-bit one in C:\Windows\System32 or the 32-bit one in C:\Windows\SysWOW64)?

What values (if any) of WIN64, PROCESSOR_ARCHITECTURE and PROCESSOR_ARCHITEW6432 does your cmd.exe have?

Have you edited makefile.mk at all?

And what command-line did you build with?

I'm on 64-bit Win7, using the 64-bit cmd.exe, with WIN64=define and PROCESSOR_ARCHITECTURE=AMD64 in the cmd.exe environment (although my 32-bit dmake.exe doesn't see it quite like that...). I haven't edited the makefile.mk at all, and I built with "dmake WIN64=define" using rubenvb's personal of the MinGW-w64 64-bit native compiler. I also tried the automated build of the cross-compiler (using "dmake WIN64=define GCCCROSS=define"). Both of those builds end up with archname=MSWin32-x86-multi-thread in the perl -V output.

sisyphus1 at optusnet

Aug 2, 2012, 4:45 AM

Post #5 of 11 (156 views)
Permalink

Re: WIN64 builds with dmake [In reply to]

----- Original Message -----
From: "Steve Hay" <Steve.Hay [at] verosoftware>
To: "Sisyphus" <sisyphus1 [at] optusnet>; "Steve Hay"
<steve.m.hay [at] googlemail>; <perl5-porters [at] perl>
Sent: Thursday, August 02, 2012 8:24 PM
Subject: RE: WIN64 builds with dmake

> Sisyphus wrote on 2012-08-02:
>>
>> ----- Original Message -----
>> From: "Steve Hay" <steve.m.hay [at] googlemail>
>> To: <perl5-porters [at] perl>
>> Sent: Thursday, August 02, 2012 6:49 AM
>> Subject: WIN64 builds with dmake
>>
>>
>>> In the course of testing the new USE_64_BIT_INT option which 1f64ae1564
>>> added to the Windows makefiles, I found that there are (existing)
>>> problems with doing a full 64-bit build (WIN64=define) when using dmake
>>> / makefile.mk.
>>>
>>> The problem is that dmake.exe is a 32-bit program, so it only sees the
>>> WOW6432 environment, even when running in the 64-bit cmd.exe. It
>>> therefore ends up seeing that PROCESSOR_ARCHITECTURE is x86 rather than
>>> AMD64 (and PROCESSOR_ARCHITEW6432 is also defined (set to AMD64)), and
>>> hence ARCHITECTURE gets wrongly set to x86 rather than x64.
>>>
>>> For MinGW-w64 this seems to succeed, producing a full 64-bit build,
>>> but with archname wrongly set to MSWin32-x86... rather than
>>> MSWin32-x64...
>>
>> It used to (up until as recent as 5.17.1, at least) set the archname
>> correctly to MSWin32-x64....
>>
>> So something must have changed ... or you might have inadvertently set
>> WIN64 = undef near the top of the makefile.mk.
>>
>> I've just built current bleadperl with 32-bit dmake and 64-bit mingw64
>> compiler. Archname was set correctly for me.
>
> That's odd.
>
> What OS are you on (specifically, 32-bit or 64-bit)? If you're on a 64-bit
> OS then what cmd.exe are you using (the 64-bit one in C:\Windows\System32
> or the 32-bit one in C:\Windows\SysWOW64)?

I'm on Vista (64-bit OS).
I used the cmd.exe from C:\Windows\System32.

> What values (if any) of WIN64, PROCESSOR_ARCHITECTURE and
> PROCESSOR_ARCHITEW6432 does your cmd.exe have?

########################
C:\comp\bleadperl\win32>set WIN64
Environment variable WIN64 not defined

C:\comp\bleadperl\win32>set PROCESSOR_ARCHITECTURE
PROCESSOR_ARCHITECTURE=AMD64

C:\comp\bleadperl\win32>set PROCESSOR_ARCHITEW6432
Environment variable PROCESSOR_ARCHITEW6432 not defined

C:\comp\bleadperl\win32>
########################

> Have you edited makefile.mk at all?

Not in any significant way.
I built blead twice - once using the x64 4.6.3 that ships with Strawberry
Perl, and then using the 4.7.0 cross-compiler that I've been using for the
last 12 months or so.

For both builds I edited the CCHOME setting to point to the appropriate
CCHOME. (Afaik, this has no relevance until we run 'dmake test'.)
For the latter build, I additionally set GCCCROSS=define (by editing the
makefile.mk).

> And what command-line did you build with?

The command used in both instances was:
dmake -f makefile.mk

(I believe that the "-f makefile.mk" amounts to no more than unnecessary
typing, but old habits are hard to break.)
It looks to me that WIN64 gets defined for me in the makefile.mk because
PROCESSOR_ARCHITECTURE=AMD64

> I'm on 64-bit Win7, using the 64-bit cmd.exe, with WIN64=define and
> PROCESSOR_ARCHITECTURE=AMD64 in the cmd.exe environment (although my
> 32-bit dmake.exe doesn't see it quite like that...). I haven't edited the
> makefile.mk at all, and I built with "dmake WIN64=define" using rubenvb's
> personal of the MinGW-w64 64-bit native compiler. I also tried the
> automated build of the cross-compiler (using "dmake WIN64=define
> GCCCROSS=define"). Both of those builds end up with
> archname=MSWin32-x86-multi-thread in the perl -V output.
>

I haven't had any trouble getting the x64 builds to figure out the archname
correctly.
I'll see if I can reproduce the problem here. (Trouble is, if I do that,
it'll then never go away :-)

It was a pleasant surprise to find that I was able to build blead with my
cross-compiler straight out of the box. (I thought that support for the
'x86_64-w64-mingw32-' prefix was going to be dismantled ... but please don't
do that unless it's necessary.)

Cheers,
Rob

Steve.Hay at verosoftware

Aug 2, 2012, 4:56 AM

Post #6 of 11 (157 views)
Permalink

RE: WIN64 builds with dmake [In reply to]

Sisyphus wrote on 2012-08-02:
>
> ----- Original Message -----
> From: "Steve Hay" <Steve.Hay [at] verosoftware>
> To: "Sisyphus" <sisyphus1 [at] optusnet>; "Steve Hay"
> <steve.m.hay [at] googlemail>; <perl5-porters [at] perl>
> Sent: Thursday, August 02, 2012 8:24 PM
> Subject: RE: WIN64 builds with dmake
>
> The command used in both instances was:
> dmake -f makefile.mk
>
> (I believe that the "-f makefile.mk" amounts to no more than unnecessary
> typing, but old habits are hard to break.) It looks to me that WIN64
> gets defined for me in the makefile.mk because
> PROCESSOR_ARCHITECTURE=AMD64

Yes, but the trouble I have is that with a 32-bit dmake.exe it sees a different environment to that seen in the command prompt -- it will see PROCESSOR_ARCHITECTURE=x86 and PROCESSOR_ARCHITEW6432=AMD64, just like you see when starting C:\Windows\SysWOW64\cmd.exe or a 32-bit perl.exe.

The only way that I can make any sense of this is if you're using StrawberryPerl's 64-bit dmake.exe (which will see the same environment that you see in the 64-bit command prompt). Is that possible? Where did you dmake come from?

>
>> I'm on 64-bit Win7, using the 64-bit cmd.exe, with WIN64=define and
>> PROCESSOR_ARCHITECTURE=AMD64 in the cmd.exe environment (although my
>> 32-bit dmake.exe doesn't see it quite like that...). I haven't edited
>> the makefile.mk at all, and I built with "dmake WIN64=define" using
>> rubenvb's personal of the MinGW-w64 64-bit native compiler. I also
>> tried the automated build of the cross-compiler (using "dmake
>> WIN64=define GCCCROSS=define"). Both of those builds end up with
>> archname=MSWin32-x86-multi-thread in the perl -V output.
>>
>
> I haven't had any trouble getting the x64 builds to figure out the
> archname correctly.
> I'll see if I can reproduce the problem here. (Trouble is, if I do
> that, it'll then never go away :-)
>
> It was a pleasant surprise to find that I was able to build blead with
> my cross-compiler straight out of the box. (I thought that support for
> the 'x86_64-w64-mingw32-' prefix was going to be dismantled ... but
> please don't do that unless it's necessary.)

No, I thought we agreed to keep it on in the end, so I left it all in there. The only MinGW-w64 compiler that isn't supported is the automated of the native 32-bit compiler, which has prefixed names for its binaries.

sisyphus1 at optusnet

Aug 2, 2012, 5:51 AM

Post #7 of 11 (154 views)
Permalink

Re: WIN64 builds with dmake [In reply to]

----- Original Message -----
From: "Steve Hay"

> Yes, but the trouble I have is that with a 32-bit dmake.exe it sees a
> different environment to that seen in the command prompt -- it will see
> PROCESSOR_ARCHITECTURE=x86 and PROCESSOR_ARCHITEW6432=AMD64, just like you
> see when starting C:\Windows\SysWOW64\cmd.exe or a 32-bit perl.exe.
>
> The only way that I can make any sense of this is if you're using
> StrawberryPerl's 64-bit dmake.exe (which will see the same environment
> that you see in the 64-bit command prompt). Is that possible? Where did
> you dmake come from?

Pretty sure it's one of the 32-bit ones provided by you on CPAN:

############################
C:\comp\bleadperl>dmake -V
dmake - Version 4.12 (Windows / MinGW)
Copyright (c) 1990,...,1997 by WTI Corp.

Default Configuration:
MAXLINELENGTH := 32766
MAXPROCESSLIMIT := 64
.IMPORT .IGNORE: DMAKEROOT
.MAKEFILES : makefile.mk makefile
.SOURCE : .NULL
DMAKEROOT *= $(ABSMAKECMD:d)startup
MAKESTARTUP := $(DMAKEROOT)\startup.mk

Please read the NEWS file for the latest release notes.
############################

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 ....

>> It was a pleasant surprise to find that I was able to build blead with
>> my cross-compiler straight out of the box. (I thought that support for
>> the 'x86_64-w64-mingw32-' prefix was going to be dismantled ... but
>> please don't do that unless it's necessary.)
>
> No, I thought we agreed to keep it on in the end, so I left it all in
> there. The only MinGW-w64 compiler that isn't supported is the automated
> of the native 32-bit compiler, which has prefixed names for its binaries.
>

No dissention from this quarter !

Cheers,
Rob

Steve.Hay at verosoftware

Aug 2, 2012, 6:27 AM

Post #8 of 11 (160 views)
Permalink

RE: WIN64 builds with dmake [In reply to]

Sisyphus wrote on 2012-08-02:
>
> ----- Original Message -----
> From: "Steve Hay"
>
>> Yes, but the trouble I have is that with a 32-bit dmake.exe it sees a
>> different environment to that seen in the command prompt -- it will see
>> PROCESSOR_ARCHITECTURE=x86 and PROCESSOR_ARCHITEW6432=AMD64, just like
>> you see when starting C:\Windows\SysWOW64\cmd.exe or a 32-bit perl.exe.
>>
>> The only way that I can make any sense of this is if you're using
>> StrawberryPerl's 64-bit dmake.exe (which will see the same environment
>> that you see in the 64-bit command prompt). Is that possible? Where did
>> you dmake come from?
>
> Pretty sure it's one of the 32-bit ones provided by you on CPAN:
>
> ############################
> C:\comp\bleadperl>dmake -V
> dmake - Version 4.12 (Windows / MinGW) Copyright (c) 1990,...,1997 by
> WTI Corp.
>
> Default Configuration:
> MAXLINELENGTH := 32766
> MAXPROCESSLIMIT := 64
> .IMPORT .IGNORE: DMAKEROOT
> .MAKEFILES : makefile.mk makefile
> .SOURCE : .NULL
> DMAKEROOT *= $(ABSMAKECMD:d)startup
> MAKESTARTUP := $(DMAKEROOT)\startup.mk
> Please read the NEWS file for the latest release notes.
> ############################

Ah, no - that's not one of mine. Mine all have -SHAY in the version:

############################
dmake - Version 4.12-20090907-SHAY (Windows / MS Visual C++)
Copyright (c) 1990,...,1997 by WTI Corp.

Default Configuration:
MAXLINELENGTH := 32766
MAXPROCESSLIMIT := 64
.IMPORT .IGNORE: DMAKEROOT
.MAKEFILES : makefile.mk makefile
.SOURCE : .NULL
DMAKEROOT *= $(ABSMAKECMD:d)startup
MAKESTARTUP := $(DMAKEROOT)\startup.mk

Please read the NEWS file for the latest release notes.
############################

I suspect you have a 64-bit dmake.exe there. If you put the following in a "makefile.mk" and run "dmake" in your 64-bit cmd.exe (where PROCESSOR_ARCHITECTURE is set to AMD64) what does it output? For me it outputs x86 since my dmake.exe is 32-bit. Does yours output AMD64?

.IMPORT : PROCESSOR_ARCHITECTURE

all :
@echo $(PROCESSOR_ARCHITECTURE)

>
> 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...

sisyphus1 at optusnet

Aug 2, 2012, 7:23 AM

Post #9 of 11 (158 views)
Permalink

Re: WIN64 builds with dmake [In reply to]

----- Original Message -----
From: "Steve Hay"

>>> The only way that I can make any sense of this is if you're using
>>> StrawberryPerl's 64-bit dmake.exe (which will see the same environment
>>> that you see in the 64-bit command prompt). Is that possible? Where did
>>> you dmake come from?
>>
>> Pretty sure it's one of the 32-bit ones provided by you on CPAN:
>>
>> ############################
>> C:\comp\bleadperl>dmake -V
>> dmake - Version 4.12 (Windows / MinGW) Copyright (c) 1990,...,1997 by
>> WTI Corp.
>>
>> Default Configuration:
>> MAXLINELENGTH := 32766
>> MAXPROCESSLIMIT := 64
>> .IMPORT .IGNORE: DMAKEROOT
>> .MAKEFILES : makefile.mk makefile
>> .SOURCE : .NULL
>> DMAKEROOT *= $(ABSMAKECMD:d)startup
>> MAKESTARTUP := $(DMAKEROOT)\startup.mk
>> Please read the NEWS file for the latest release notes.
>> ############################
>
> Ah, no - that's not one of mine. Mine all have -SHAY in the version:

Right you are - but I think it's 32-bit.
It has the same checksums as the dmake.exe that ships with the 32-bit
Strawberry Perl 5.16.0 (relocatable):

MD5: cad07f0bb26de187fe85c8e567bcdd6e
SHA1: 1a20d65fbbdcb39c28d633abb109c4d7752dbadf
SHA256: 4ebf3ca5cfc13b1c6f9556542946ef8a93b835542eb4c585e7a442d4fa82587b

> I suspect you have a 64-bit dmake.exe there. If you put the following in a
> "makefile.mk" and run "dmake" in your 64-bit cmd.exe (where
> PROCESSOR_ARCHITECTURE is set to AMD64) what does it output? For me it
> outputs x86 since my dmake.exe is 32-bit. Does yours output AMD64?
>
> .IMPORT : PROCESSOR_ARCHITECTURE
>
> all :
> @echo $(PROCESSOR_ARCHITECTURE)

It outputs 'x86'.
I also dug up your 4.12-20090907. It, too, outputs 'x86' for me - which is
exactly as you expected.
I'll give yours a try at building blead when I get a chance - but
unfortunately I'm going to have to drop this until Monday.

>> 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 ;-)

Cheers,
Rob

Steve.Hay at verosoftware

Aug 3, 2012, 12:55 AM

Post #10 of 11 (154 views)
Permalink

RE: WIN64 builds with dmake [In reply to]

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
.ELSE
WIN64 = undef
.ENDIF
.ENDIF

ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
.IF "$(ARCHITECTURE)" == "AMD64"
ARCHITECTURE = x64
.ENDIF

ARCHNAME = MSWin32-$(ARCHITECTURE)

all :
@echo ARCHNAME=$(ARCHNAME)

sisyphus1 at optusnet

Aug 3, 2012, 5:42 PM

Post #11 of 11 (154 views)
Permalink

Re: WIN64 builds with dmake [In reply to]

> Steve Hay <Steve.Hay [at] verosoftware> wrote:

> 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...

UIM, it's currently a fairly simple scenario.
If you want to build a 32-bit build of perl on a 64-bit Windows OS, you specify WIN64=undef; else you don't specify a WIN64 setting at all.

The problem with that, as I see it, is that it runs against normal expectations. (If you need to specify WIN64=undef for one situation, then one expects that it will be necessary to do WIN64=define for another.)

Perhaps it's clearer if instead of specifying 'WIN64=undef' for our 32-bit builds on 64-bit systems we had to specify '32on64=define', which then in turn sets WIN64 to undef.
(And we make '32on64=undef' a no op.)
This would reduce confusion, but is still not as good as auto-detection.

The only problem with auto-detection is that it first needs to determine whether the compiler is 32-bit or 64-bit ... which means that it has to compile and run a C program.
But maybe that's not such a big deal.

Cheers,
Rob

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads