Bug #96815 for Win32-API: $(AS) not set correctly

Sun Jun 29 10:07:33 2014 sisyphus [...] cpan.org - Ticket created

Subject:

$(AS) not set correctly

Hi, Trying to build Win32-API-0.77, I hit the following problem. With perls built using mingw64 (64-bit) port of gcc-4.7.0, the generated Makefile's "$(AS)" is set to "as". However, for this particular compiler (which is technically a cross-compiler) the correct setting is "x86_64-w64-mingw32-as". It's not clear to me how to correct that setting. Any ideas ? As a workaround I can create a copy of "x86_64-w64-mingw32-as.exe" and call it "as.exe". That gets the job done, but I would prefer to not have to do that. Cheers, Rob

Sun Jun 29 11:52:38 2014 BULKDD [...] cpan.org - Correspondence added

On Sun Jun 29 10:07:33 2014, SISYPHUS wrote: Show quoted text

> Hi, > > Trying to build Win32-API-0.77, I hit the following problem. > > With perls built using mingw64 (64-bit) port of gcc-4.7.0, the > generated Makefile's "$(AS)" is set to "as". > However, for this particular compiler (which is technically a cross- > compiler) the correct setting is "x86_64-w64-mingw32-as". > > It's not clear to me how to correct that setting. Any ideas ? > > As a workaround I can create a copy of "x86_64-w64-mingw32-as.exe" and > call it "as.exe". That gets the job done, but I would prefer to not > have to do that. > > Cheers, > Rob

Who made your dmake's "startup" directory which has ".mk" files in it like config.mk local.mk and startup.mk? The AS macro comes from dmake, not from Win32::API. I've had similar problems with the AS macro being broken on the Mingw/dmake package that ActivePerl ships and it eventually was fixed in https://rt.cpan.org/Public/Bug/Display.html?id=89440 . I don't feel this is a perl module level issue (makefile.pl), but a dmake issue. make macros that are always defined out of the box should work out of the box without requiring fixing logic to be copy pasted into every perl module that wants to use that macro. Fixing dmake will allow $(AS) to work everywhere, not just in Win32::API.

Sun Jun 29 11:52:38 2014 The RT System itself - Status changed from 'new' to 'open'

Sun Jun 29 21:17:09 2014 sisyphus [...] cpan.org - Correspondence added

On Sun Jun 29 11:52:38 2014, BULKDD wrote: Show quoted text

> On Sun Jun 29 10:07:33 2014, SISYPHUS wrote:

Show quoted text

> I don't feel > this is a perl module level issue (makefile.pl), but a dmake issue.

Yes, I don't think it's a Win32::API issue. I merely raised the issue here as a "starting point" because this is the first module I've come across that has been affected by this issue. I use the *same* dmake for *all* of my Windows perls. For some of those perls $(CC) needs to be set to 'gcc', for others it needs to be 'x86_64-w64-mingw32-gcc'. Similarly, $(AR) can be either 'ar' or 'x86_64-w64-mingw32-ar' depending upon which compiler built the perl that's being used. The generated Makefile always sets $(AR) and $(CC) correctly for the particular perl. I presume that this happens via the influence of ExtUtils::MakeMaker ... and I wonder whether ExtUtils::MakeMaker could be amended to do the same as regards $(AS) ? I'll ask about this on the makemaker mailing list. In startup.mk I see: AS *:= as and I also see AR *:= ar AR always gets set correctly, so I think the same should be possible for AS. Thanks for the pointers ! Cheers, Rob

Tue Jun 02 23:02:49 2015 BULKDD [...] cpan.org - Correspondence added

I probably fixed this in commit "32 bit GCC builds now use the assembler and real asm code" since the dmake in very old strawberry perls had "AS" set to "masm" through config.mk/dmake's startup files. The real fix would probably be EUMM defining AS macro, but that is for EUMM to include that feature, not me.

Tue Jun 02 23:02:57 2015 BULKDD [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Jun 02 23:02:58 2015 BULKDD [...] cpan.org - Fixed in 0.82 added