Compiling C/C++ based Modules under ActiveState using MinGW

[syphilis]

First thing to do, of course, is to install 'dmake.exe' and the MinGW compiler. (Note that nmake can also be used instead of dmake. Nmake15.exe contains an older version of nmake that doesn't provide the milage that dmake delivers - though, depending upon what you build, you may never be bitten by this lack of milage. Recent versions of nmake are fine.)

To install dmake and MinGW, simply run ppm install MinGW

Note: From here on, I'm assuming that dmake is being used. If you're using nmake, then it's just a matter of substituting "nmake" for "dmake" in the commands.

So long as you're running build 815 (or later) of ActiveState Perl, that's theoretically (see the Bugs and Their Fixes section below) all you need to do. Assuming that both MinGW and dmake are in your path, and that neither Microsoft's cl compiler nor nmake can be found in the path, then ActiveState Perl will automatically use dmake and MinGW, and the appropriate %Config values will be loaded. (If cl is in your path, and you want to use gcc, you must either remove cl from the path, or set the ACTIVEPERL_CONFIG_CC environment variable to gcc. If nmake is found in your path, then you can't use dmake - but nmake will work just as well with gcc as it does with cl. See perldoc ActivePerl::Config for details.)
You can then build C/C++-based modules by simply downloading the source tarball from CPAN, extracting it to some location, cd'ing to that location and running:

perl Makefile.PL
dmake test
dmake install

Or you can do it using the automation provided by CPAN.pm.

For builds earlier than build 815 (including builds of perl 5.6), it is necessary to also install ExtUtils::FakeConfig in accordance with the instructions found in its README.txt. (Note that one can also use ExtUtils::FakeConfig with builds 815 and later, if one wishes). That done, it's then just a matter of building modules by running:

perl -MConfig_m Makefile.PL
dmake test
dmake install

It's the '-MConfig_m' that loads EU::FC's Config_m.pm (and hence the appropriate %Config values). However, in the building of various perl modules (eg PDL), the Makefile.PL may run 'perl -e' commands that need to be run as 'perl -MConfig_m -e'. In order to ensure that EU::FC's Config_m.pm values are loaded every time perl is run, we can just set the perl5opt environment variable to -MConfig_m:

set perl5opt=-MConfig_m

Having done that, we no longer need to specify the -MConfig_m option, so it's back to running:

perl Makefile.PL
dmake test
dmake install

Bugs and Their Fixes

I don't know of any bugs as regarding version 0.09 (or later) of ExtUtils::FakeConfig, so if you're using its -MConfig_m option to load the appropriate %Config values, then you can ignore what follows. However, if you're relying on the automation provided by ActiveState builds prior to build 821, then there are some areas where ActiveState haven't quite got it right.

At time of original writing, build 820 was the latest ActivePerl build. I know of only one problem with it. $Config{obj_ext} remains set to '.obj' (as can be seen by running perl -V:obj_ext). But it needs to be set to '.o'. To fix, open up perl/lib/Config.pm, locate the line obj_ext => '.obj', and remove it (or comment it out).

IIRC, builds 815 to 819 insisted on setting $Config{ld} to 'gcc'. Running perl -V:ld will reveal what $Config{ld} is set to. If it reports 'gcc', open up ActivePerl/Config.pm which, with builds 815 to 818 is in perl/site/lib, but is in perl/lib with subsequent builds. Find the line that specifies _override("ld",        "gcc"); and change the 'gcc' to 'g++'.

While you've got that file open, check to see what perl -V:lib_ext reports. If it reports that 'lib_ext' is set to '.a', then all is well, but if it reports that 'lib_ext' is set to '.lib' then add _override("lib_ext",        ".a"); to that same list of _override() calls. Also, in the same file (near the top), find the lines:

    ldflags
    libc
    libs

and change that to:

    ldflags
    libc
    lib_ext
    libs

And then, for that change to the $Config{lib_ext} setting to take effect, it is necessary to open perl/lib/Config.pm, find the line lib_ext => '.lib', and either remove that line or comment it out.

These are the only such bugs I know of - though I've never used build 815 or 818. (Build 816 should be avoided at all costs - for unrelated reasons).

Cheers,
Rob
Updates: Altered the advice on how to install dmake and MinGW on the basis of jdporter's comments;
Amended "per5opt" to the correct "perl5opt" - thanks Intrepid
Build 822 of ActivePerl has since been released - no known problems wrt MinGW and dmake.
Changed (again) instructions on the installation of dmake and MinGW, as these can now be installed using ppm.
Corrected info given about how ActivePerl determines which compiler/make to use.

[jdporter]

I had problems with the MinGW installer you pointed to (5.0.3); but the latest one (5.1.3) worked o.k.

I encountered an error whilst dmaking a certain module:

Undefined subroutine &main::UpdateHTML_blib called at -e line 1.

(This call is generated by perl Makefile.PL.) The solution is to delete or rename Perl\site\lib\ActivePerl out of the way. The one in Perl\lib is newer, but isn't found due to the order of entries in @INC. (I hit this problem in ActiveState build 819.)

There was another error (or warning): the generated Makefiles call false at least once, but the MinGW installation doesn't include this executable. However, this error can be ignored, AFAICT.

Also, heed the admonition to run dmake -S -S if you receive it.

I think it would helpful if you'd mention what values you put in dmake's config.mk file (or any other files), since the dmake documentation doesn't really provide any guidance. I used the following, but I'm really not sure if/why it works:

   OS            *:= winnt
   OSRELEASE     *:= mingw
   OSENVIRONMENT *:= gcc

[syphilis]

I had problems with the MinGW installer you pointed to (5.0.3); but the latest one (5.1.3) worked o.k.

Oh ... I thought my link was to the latest available .... but apparently not. Can you send me the correct link(s) and I'll amend the post.

I encountered an error whilst dmaking a certain module

Which module ? I know I've seen that error, but that's about all I can recall about it.

The solution is to delete or rename Perl\site\lib\ActivePerl out of the way. The one in Perl\lib is newer ...

I don't quite follow. What exactly is it in Perl\lib that's "newer" ? Also Perl\site\lib\ActivePerl doesn't exist on build 819 (or 820).

I can't recall ever seeing any warnings or errors in relation to false - and I've never been asked to run dmake -S -s. (Do you have any further info on these aspects ?)

I think it would helpful if you'd mention what values you put in dmake's config.mk file (or any other files)

I've never put anything in dmake's config.mk file (or any other dmake files). All I ever do is place the startup directory and dmake.exe in the same location, and make sure that location is in the path. Perhaps that's what I should have said in my post - instead of referring to the dmake distro's Readme.txt ?

Thanks for taking the time to raise all of this, btw.

Cheers,
Rob

[jdporter]

Can you send me the correct link(s) and I'll amend the post.

If you do that, it will be out of date soon enough again. Instead, link to MinGW.exe download from SourceForge, which always shows the "current".

Which module?

If it mattered, I would have included it. The point is to prepare people for this event regardless of which module they're installing when it happens.

What exactly is it in Perl\lib that's "newer" ?

Perl\lib\ActivePerl is newer than Perl\site\lib\ActivePerl.

Perl\site\lib\ActivePerl doesn't exist on build 819

Ah, that may be true. It's probably left over from when I upgraded from an earlier build. At any rate, if I had this problem, others may as well.

Do you have any further info on these aspects?

Sorry, no. I figured it may not be a usual thing, which is why I said "if you receive it".

Perhaps that's what I should have said in my post - instead of referring to the dmake distro's Readme.txt?

Sure.

Thanks for taking the time to raise all of this, btw.

My pleasure. Thanks for writing the tutorial in the first place! You saved me (and many others, I'm sure) countless hours of tedious rediscovery.

[syphilis]

Undefined subroutine &main::UpdateHTML_blib called at -e line 1.

Aaah ... it comes back to me now (with the help of Mr. Google). You would have had exactly the same problem with nmake - and removing Perl\site\lib\ActivePerl will fix that problem, though there may be other issues that need to be dealt with. Build 819 does not have Perl\site\lib\ActivePerl, but earlier builds do. When you install 819 over the top of an earlier build, Perl\site\lib\ActivePerl from that earlier build remains in place - and will be found before 819's Perl\lib\ActivePerl. In this particular instance, the wrong version of DocTools.pm is being loaded.

Here's a posting from Jan Dubois on the same issue (raised elsewhere):
-- quote --
I assume you installed AP819 on top of a previous ActivePerl installation. This is a problem because 819 has all bundled modules installed in the lib tree and not in the site/lib tree. It also changes the order of entries in @INC to put site/lib in front of lib. This allows you to update bundled modules with the new PPM4 and have those new modules override the old ones in lib. If you install on top of an older ActivePerl, then you will have old module versions in site/lib that now shadow the new entries in lib. It would be best to do a clean install of AP819.
-- end quote --

I think this is an issue that relates only to build 819 - with build 820 onwards, attempting to install over the top of a pre-819 build is detected and disallowed.

Cheers,
Rob