I got around to trying my own suggestion for altering the Config for StrawberryPerl in the manner I proposed, in the discussion over here, recently. I had said:

So a superior approach might be to set cc in the Perl Config-heavy.pl file to the fully-qualified pathname where the mingw gcc that's shipped with Strawberry is installed. That way the right gcc is always called:

• Config_heavy.pl: cc='gcc'
• becomes: cc='C:/strawberry/c/bin/gcc'

Strawberry's setup program alters the MSWindows system PATH (%Path%) env var but that's inherently fragile when something later (like a brain-damaged user or other software setup program) could come along and clobber that.

The results thus far have not been ok. The error seen pertains to how EU::MM is deciding what the semantics for invoking the link step of extention library file creation ought to be... see Link: extracted snippet from the Makefile generated by ExtUtils::MakeMaker on Strawberry, showing how it tells make to direct the compilation of the extention lib (in this case, for the extension module List::MoreUtils).

Those familiar with the technicalities of the GNU ld linker and how gcc syntax for its invocation works will recognize that -out: and -def: are completely unGNUish and in fact are the parameter syntax for the Microsoft linker.

This is drearily familiar because this is what using Perl the way I want to on MS Windows has always been like. Things often "almost work" but not quite. In this case what I believe is happening is that somewhere in the depths of the MakeMaker apparatus, somebody coded a fragile, over-simplified test for the Config value of cc; and if it is not just plain gcc in Config, the apparatus decides that 'that other compiler' (Microsoft's cl.exe) must be the one available. I am surely going to check that out and see if I'm right ...

Ok, checked, and it's the line in ExtUtils::MM_Win32 that does
my $GCC     = $Config{'cc'} =~ /^gcc/i ? 1 : 0;
that is responsible for this badness. That was a piece of coding lacking in foresight if ever I have seen one. How about a more reasonable, reliable, flexible
my $GCC     = ($Config{'cc'} =~ /^gcc/i or $Config{'cc'} =~ /gcc(?:\.exe)?$/i) ? 1 : 0;
instead?

It is such a bummer that the way adding modules on MS Windows works, is based on these contortions deemed necessary for the historical MS Studio tools etc, then awkwardly twisted back to the GNU toolset provided by the MinGW project. MinGW GCC + friends are basically the familiar *nix tools and work so very similarly, yet where Perl is concerned MinGW's gcc is some half-known mystery that can barely be dealt with. Apparently that's 'OK' because the main port of Perl to MS Windows is fashioned in such a way as to build and interoperate mainly with the Microsoft proprietary development system ;-/.

What I am truly wishing for is a way to override ExtUtils::MM_Unix code with MinGW-compatible syntax only instead of going anywhere near that damn ExtUtils::MM_Win32 module. ;-/

The other thing I am most wishing for from Strawberry and similar Win32 perls is that the GNU make tool can be chosen to build CPAN modules, instead of the dmake program. I know GNU make inside and out and use it for building all my other software. It's apparently still a notion out there that "GNU make on Windows as MinGW provides it, isn't working well enough to build Perl modules"; but MinGW's build of GNU make now reflects steady improvement and is perfectly up to that task. And it's bundled as part of the MinGW included in StrawberryPerl.

Two in the box, ready to go!
We be fast and they be slow!

      — GhostBusters II