|Think about Loose Coupling|
..this issue is avoided in this case by using Strawberry Perl, which presumably comes with the very same compiler that was used to compile Strawberry Perl (gcc in the form of minGW)
That is correct ... but just to confuse you, you should be able to use the very same compiler (and the very same dmake) with recent ActiveState builds of perl.
Also... is there a compiler flag that redirects the output to a log file
Then check the relevant file (ie p.txt, d.txt, t.txt, or i.txt) to get the output.
I haven't tried to build GTK2 (nor do I presently intend to), but your "precompiled Gtk2 and Glib, binaries and libraries as provided by the Sourceforge Project" should be usable with your MinGW (though you might need to additionally link to some of the MinGW libs - eg libgcc.a ... error messages would be handy). You shouldn't need "the include and lib directories from the Windows Platform SDK" - and I would suggest making them invisible (to begin with, anyway). Usually, a lot of the problems with these modules is that the authors feel obliged to try to guess where the external libraries are located. It's a regrettable state of affairs ... often a result of a misguided attempt to get the module to build via the automated CPAN.pm build procedure. Anyway ... let's start by looking at your 'dmake' output. What is it ?