|
|
|
| Welcome to the Monastery | |
| PerlMonks |
RFC: Compiling C/C++ based Modules under ActiveState using MinGWby syphilis (Archbishop) |
| on May 08, 2007 at 13:14 UTC ( #614131=perlmeditation: print w/replies, xml ) | Need Help?? |
|
Some time ago tachyon wrote a tutorial entitled
A Practical Guide to Compiling C based Modules under ActiveState using Microsoft C++.
It's also a fairly straightforward task to build modules on ActiveState Perl (or, indeed, any
MSVC6-built multi-threaded perl) using 'dmake' and the MinGW (gcc) compiler - yet information on how to do this seems to be
scattered and incomplete. The following proposed tutorial is aimed at addressing that sad state of affairs.
(AFAIK it's complete ... but there's no guarantee that my knowledge extends very far :-)
Compiling C/C++ based Modules under ActiveState using MinGW 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, grab the latest version of it from CPAN and install it as per the instructions in the 'Readme.txt' that comes with the distribution. For MinGW, go to sourceforge, and download and then run the installer. You'll also then need to add the MinGW\bin folder to the path - unless the installer does that for you. (I can't recall whether it does that.) 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 what follows. 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 they are the first compiler and make utility found in the path, then those recent builds of ActiveState Perl will recognize that dmake and MinGW are being used, and the appropriate %Config values will be loaded. 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: 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: 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: Having done that, we no longer need to specify the -MConfig_m option, so it's back to running:
Bugs and Their Fixes I don't know of any bugs as regards the current version (0.09) 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 the recent ActiveState builds, then there are some areas where ActiveState haven't quite got it right. At time of writing, build 820 is 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: and change that to: 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 Update: Acknowledge that nmake can also be used - as pointed out by bart and TGI.
Back to
Meditations
|
|
||||||||||||||||||||||||