The dlltool conundrum on mswin32.mingw

I was focused in this effort on the case wherein the platform OS is MS Windows and the "subplatform" is defined by the GNU toolset provided by the volunteer MinGW project, which includes the GNU Compiler Collection (GCC). Another example of a subplatform of MS Windows would be the VisualStudio 2008 from Microsoft. GCC, being free (in both senses) and standard across many types of systems, is a particularly attractive choice for those not employed at a workplace that provides and enforces the use of a proprietary commercial C compiler toolchain.

When the default EUMM -based Makefile.PL is run in the case of a C extension module like XML::Parser::Expat (the backend to XML::Parser), there is a section of Makefile code "emitted" by the method named ExtUtils::MM_Win32::dynamic_lib. This section of Makefile text includes a make rule (recipe) for building the dynamic lib (relocateable object code) or DLL which implements the C part of the extension. The rule will cause make to do the invocation of a program called dlltool which hasn't been required for most uses of mingw for many years now. It's obsolete code that targets a generation of mingw which is, in F/LOSS terms, practically ancient history.

One improvement I sought in writing the reworked build support for XML::Parser was the elimination of the baroque, little-understood, time consuming and unneeded invocation of dlltool in favor of a cleaner, up to date and more understandable direct creation of the DLL through invoking gcc. This way of calling gcc is much more congruent with the operation of gcc on Unix-like platforms that are familiar to many users with some background in compiling C code — like GNU/Linux.

The override that does the change to this method dynamic_lib() is located (at present) in the file hints/mswin32.pl in the source kit tree you'll get when you unpack one of the archives listed above. But please note that this way of overridding this method is not customary or best!. It was done in this way and in this file due to the particular unique process I went though of writing the overall refactoring, and may be moved out and done in a different (and better) way later.

Here's the excerpt from that file: the code that implements the overridden method (with comments as they appear in the source):

        package ExtUtils::MM_Win32;

    # clobber this one with extreme prejudice because of the gawd-awfu
+l bs
    # it is, for thinking that mingw gcc is still this clunky.

        sub dynamic_lib {
            my($self, %attribs) = @_;
            return '' unless $self->needs_linking(); #might be because
+ of a subdir
            return '' unless $self->has_link_code;

            my($otherldflags) = $attribs{OTHERLDFLAGS};
            my($inst_dynamic_dep) = $attribs{INST_DYNAMIC_DEP} || "";
            my($ldfrom) = '$(LDFROM)';
            my $tabchar = "\t";
            my(@m);

            my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
            $dllname =~ /(....)(.{0,4})/;
            my $baseaddr = unpack("n", $1 ^ $2);
            $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $ba
+seaddr);

            push(@m,'
# This section creates the dynamically loadable $(INST_DYNAMIC)
# (ms windows DLL file) from $(OBJECT) and possibly $(MYEXTLIB).
OTHERLDFLAGS ='      .($otherldflags     ? " $otherldflags"  : "")    
+.'
INST_DYNAMIC_DEP ='  .($inst_dynamic_dep ? " $inst_dynamic_dep" : "") 
+.'

$(INST_DYNAMIC): $(OBJECT) $(MYEXTLIB) $(BOOTSTRAP) \
                 $(INST_ARCHAUTODIR)$(DFSEP).exists \
                 $(PERL_ARCHIVE) $(INST_DYNAMIC_DEP)
');
            push(@m, $tabchar,
                 q{$(CC) -o $@ $(LDDLFLAGS) }
               . $ldfrom ." \\\n"
               . q{ $(OTHERLDFLAGS) $(MYEXTLIB) $(PERL_ARCHIVE) $(LDLO
+ADLIBS)
}
            );
          # return our assembled Makefile text:
            join('',@m);

        }  #  END of sub
[download]

One thing of note is that the sub above is just Perl. Where there are strings that look like Makefile text, they are just Perl scalar strings. There is no "source filtering" or other eldritch magic going on here, merely using Perl to manipulated text, something that Perl is reputed to be rather good at ;-).

The override imposed on this section-builder method replaces an invocation that looks like this:

gcc -o blib\arch\auto\XML\Parser\Expat\Expat.dll -mdll -s -LE:/perls/S
+trawberry_Perl_510_0/perl/lib/CORE -LE:/StPerl_Bundled_mingw/lib -O2 
+-mconsole -Wl,-export-all-symbols,-output-def,XML_Parser_Expat.def,-o
+ut-implib,XML_Parser_Expat.dll.a Expat.o \
 -Wl,--image-base,0x35130000  C:\strawberry\perl\lib\CORE/libperl510.a
+ e:/stperl_bundled_mingw/lib/libexpat.a e:/StPerl_Bundled_mingw/lib/l
+ibgdi32.a e:/StPerl_Bundled_mingw/lib/libwinspool.a e:/StPerl_Bundled
+_mingw/lib/libcomdlg32.a e:/StPerl_Bundled_mingw/lib/libole32.a e:/St
+Perl_Bundled_mingw/lib/liboleaut32.a e:/StPerl_Bundled_mingw/lib/libn
+etapi32.a e:/StPerl_Bundled_mingw/lib/libuuid.a e:/StPerl_Bundled_min
+gw/lib/libws2_32.a e:/StPerl_Bundled_mingw/lib/libmpr.a e:/StPerl_Bun
+dled_mingw/lib/libwinmm.a e:/StPerl_Bundled_mingw/lib/libversion.a e:
+/StPerl_Bundled_mingw/lib/libodbc32.a e:/StPerl_Bundled_mingw/lib/lib
+odbccp32.a
 
 Creating library file: XML_Parser_Expat.dll.a
[download]

I've inserted extra newlines in a couple of places in a futile attempt to make this console output more parseable to the human eye. But notice that the operations called for in the second instance involve less text and a single invocation of gcc.