Re^2: [Win32] Overriding dmake's $(AS)

I think I'm on a different page :-)

I have a number of perls (some 32-bit, some 64-bit) all of which use the same (32-bit) dmake.
I have no problems with that, except for when it comes to building Win32::API.

For all other modules, it works fine.
With the 32-bit perls, running perl Makefile.PL generates a Makefile that specifies:
AR = ar.exe
CC = gcc.exe
That is correct, and as it should be.

With the 64-bit perls (which, obviously, use a different compiler), running perl Makefile.PL generates a Makefile that specifies:
AR = x86_64-w64-mingw32-ar.exe
CC = x86_64-w64-mingw32-gcc.exe
That is correct, and as it should be.

However, when building Win32::API, the assembler (as.exe) gets invoked.
No problem on the 32-bit perls - the assembler gets correctly invoked as 'as.exe'.
But on the 64-bit perls, it also gets invoked as 'as.exe' - which is incorrect as it ought to be invoked as 'x86_64-w64-mingw32-as.exe'.

Obviously there's some process somewhere that handles the correct setting of AR.
I would like to apply that same process to AS so that it, too, gets set correctly for the 64-bit perls.
But I don't know what/where that "process" actually is.
Any ideas ?

UPDATE: Seems that "ar", like "cc", is set in %Config.
But there is no %Config setting for "as" ... so I think I'm probably faced with hacking the dmake files (or copying 'x86_64-w64-mingw32-as.exe' to 'as.exe').
Ought there be a %Config setting for the assembler ?

Cheers,
Rob

Comment on Re^2: [Win32] Overriding dmake's $(AS) Select or Download Code

Replies are listed 'Best First'.
Re^3: [Win32] Overriding dmake's $(AS) by BrowserUk (Patriarch) on Jul 11, 2014 at 03:28 UTC
Ought there be a %Config setting for the assembler ? You decide. You've described an excellent case for it being so. And you are the only one who comes around here that has: the vaguest inclining of how this stuff works; and the tuits to make it happen. Decide, and go tuit. Or not as you see fit. You have as much expertise and far more tuits on this subject than anyone else who still visits this place on a regular basis. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^4: [Win32] Overriding dmake's $(AS) by syphilis (Archbishop) on Jul 11, 2014 at 09:18 UTC
You've described an excellent case for it being so Yes, I think you're right. I'll research it a bit more and then run it by p5p and see what happens. There may be a view that it's up to the make utility to set this correctly - and that I really ought to be using different make utilities for the different compilers. (There's one way to find out whether such a view prevails :-) Anyway ... thanks for the encouragement !! Cheers, Rob	[reply]
Re^3: [Win32] Overriding dmake's $(AS) by Anonymous Monk on Jul 11, 2014 at 02:54 UTC
Ought there be a %Config setting for the assembler ? Hmm, perl doesn't use it, so I guess not :/ maybe :) If you look at Win32-API-0.77\Makefile.PL you'll see it uses `$(AS)` but it doesn't define it , which probably means it simply defaults to 'as' You can always arrange for `perl Makefile.PL AS=x86_64-w64-mingw32-as.exe` dmake should also pick it up from %ENV via `set AS=x86_64-w64-mingw32-as.exe` or via sitecustomize $ENV{AS}='x86_64-w64-mingw32-as.exe'; Or give it to Makefile.PL via $ENV{PERL_MM_OPT} https://metacpan.org/pod/ExtUtils::MakeMaker#PERL_MM_OPT So no Makefile hacking required, set some %ENV vars as usual :) I guess whomever built your toolchain chose `x86_64-w64-mingw32-as.exe` so they can dump all the .exe in the same directory :) choices complicate choices :)	[reply] [d/l] [select]