Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

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

by syphilis (Archbishop)
on May 08, 2007 at 13:14 UTC ( [id://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:
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 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:
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
Update: Acknowledge that nmake can also be used - as pointed out by bart and TGI.

Replies are listed 'Best First'.
Re: RFC: Compiling C/C++ based Modules under ActiveState using MinGW
by bart (Canon) on May 09, 2007 at 11:39 UTC
    First thing to do, of course, is to install 'dmake.exe' and the MinGW compiler.
    I'm wondering, why do you need dmake, in your opinion?

    I'm succesfully building XS modules on ActivePerl with MinGW and Microsoft's nmake. I can see no good reason to switch. Installing nmake was totally hassle-free, but I've never installed dmake.

      I'm wondering, why do you need dmake, in your opinion?

      You don't - I was shying away from that because I don't have a link to a recent and reliable version of nmake. I know there's an 'nmake15' (or an 'nmake1.5' ... or something like that) that's readily locatable, but it fails to build PDL and probably some other modules as well. I don't really want to link to a make utility that doesn't provide the milage offered by dmake.

      I'll update the meditation to include mention of the fact that one can use nmake with MinGW. If you can provide a link to a recent and reliable version of it, I'll add that to the meditation, too.

      Thanks for the heads up.

      Cheers,
      Rob
Re: RFC: Compiling C/C++ based Modules under ActiveState using MinGW
by TGI (Parson) on May 09, 2007 at 17:37 UTC

    An excellent (and much needed) update!

    I'm surprised you didn't mention Randy Kobes' excellent PPM::Make module.

    I am a big fan of using only one package management system for my software whenever possible. So I use PPM exclusively on my Windows systems. Since many modules lack available PPMs, PPM::Make makes the process of creating and installing PPMs very simple.

    I build using mingw and nmake. I use the following steps:

    perl Makefile.PL nmake nmake test make_ppm ppm install foo.ppd

    I do my installs the hard way, because I like to be able to see each step in easy bite-sized pieces that my tiny brain can handle. If I wanted to just install and go, I could use the ppm_install command and do everything all in one go.


    TGI says moo

      I'm surprised you didn't mention Randy Kobes' excellent PPM::Make module

      Sorry, I meant to reply to this earlier - got waylaid :-)

      I don't follow the relevance of this wrt this particular meditation/tutorial. We all know that randyk does only work of the highest quality (not to mention the admirable character of the man), but I think a treatise on PPM::Make would be more appropriate in a meditation regarding the building of PPM distro's. When it comes to building and installing modules, I think the relevance of PPM::Make is somewhat tenuous (to say the least) - which is the reason that I haven't mentioned it. (And I do want to keep it simple.)

      I think I see where you're coming from, btw - doing it that way means that PPM keeps track of everything that's installed.

      (Great sig !! - I work in the dairy industry :-)

      Cheers,
      Rob
        I think I see where you're coming from, btw - doing it that way means that PPM keeps track of everything that's installed.

        Yep. My rationalization for suggesting PPM::Make is that it a basic part of the module acquisition process ( Download -> Build -> Install ). I guess my thinking lumped build and install together, while you were focusing just on the build portion of the process. I definitely see your point.

        Your node is certainly a welcome update. I recall the frustration I went through trying to get some modules compiled and installed while struggling under a ludicrous deadline. A resource like this would have been invaluable. I hope my above response was not taken as an attempt to denigrate your contribution.

        Maybe when I get out from under my latest ludicrous deadline, I'll get around to writing a review of PPM:Make or a tutorial on building PPMs. Anyone know where I can purchase a metric ton of tuits?


        TGI says moo

Re: RFC: Compiling C/C++ based Modules under ActiveState using MinGW
by zentara (Archbishop) on May 08, 2007 at 16:33 UTC
    I'm sure this will help alot of people, but..... I think it's easier to just learn linux, where it all works flawlessly without all the hoops to jump through. :-)

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      Zentara said:I think it's easier to just learn linux, where it all works flawlessly without all the hoops to jump through. :-)

      Indeed, the *NIX operating systems were (and are) written by Programmers with the Tools that Programmers need integrated (for some value of 'integration') with each other. In the Linux/Solaris/*BSD environments I don't have to jump through hoops. Unfortunately, about 75% of my customer base is running on some flavor of Windows, and my code has to work for them as well.

      I develop in Perl on a Linux machine. I do my testing and first level QA on a Solaris desktop and a Wintel laptop. When I turn the package over to the real QA group, they test it on a combination of various version of Windows on different hardware platforms. I have supply a port all of the Modules that I used in my development environment, or QA (quite rightly) will fail my code as "un-testable and un-verifiable; not approved for production".

      Like many things, it's all a compromise....

      ----
      I Go Back to Sleep, Now.

      OGB

      I think it's easier to just learn linux, where it all works flawlessly without all the hoops to jump through.
      Rrrright. Perl5porters have nothing to do, they're just wasting their time — they just like it better than playing silly video games.

      You're so wrong if you believe there are no platform dependencies in XS modules. C compilers are not standardized.

      I think it's easier to just learn linux, where it all works flawlessly without all the hoops to jump through

      If ActiveState had got it right (which will hopefully be the case with the release of build 821) there would currently be no hoops to jump through at all - save having to install dmake and MinGW. Even if you use the EU::FC approach to the compilation of modules on ActiveState perl, there aren't that many hoops to jump through. And once you have jumped through those hoops then you have something that does work flawlessly ..... (where I'm using the word "flawlessly" with the same poetic licence that zentara employed :-)

      Cheers,
      Rob
      Women also make you jump through hoops -- the easy road isn't always beter
      Ok, I stand corrected, I'll shut up now. :-)

      I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://614131]
Approved by BrowserUk
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (3)
As of 2024-03-19 04:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found