in reply to Compiling Perl Modules on Windows

I haven't tried Strawberry Perl, but with Activestate's Perl I've had much more success with the MinGW compiler than with MSVC++ (using nmake with both).

With some versions of ActivePerl you have to also install ExtUtils::FakeConfig and modify the values in that module, specifying whether you're using "nmake" or "dmake", for example, and which compiler you're using. I also had to take out a line trying to link to 'libperl56.a'

Sometimes ActivePerl seems to spot that you've got MinGW on board and adjust things accordingly, so you don't have to do all this. "perl -V:cc" should tell you "gcc/MinGW" if so.

Replies are listed 'Best First'.
Re^2: Compiling Perl Modules on Windows
by syphilis (Archbishop) on May 01, 2007 at 11:49 UTC
    Sometimes ActivePerl seems to spot that you've got MinGW on board and adjust things accordingly

    I think that, starting with build 815, it should "spot that you've got MinGW on board". For earlier builds (including the 5.6 builds) you'll need ExtUtils::FakeConfig - which actually provides better milage than the automatic procedure that kicks in with build 815 and later.

    There's a few bugs in the set up that ActiveState provide (but EU::FC seems to get everything right). For builds 815-819 I think you'll find that 'perl -V:ld' tells you 'ld' is set to 'gcc', whereas it should be set to 'g++'. (It only makes a difference when an attempt is made to compile C++ code.) And, for some reason they left 'lib_ext' set to '.lib' - which can also pose problems. With build 820, they've pretty much got everything right - one exception is that 'perl -V:obj_ext' reports '.obj' instead of the correct '.o'. (To fix, comment out the line obj_ext => '.obj', in Perl/site/lib/Config.pm'.)

    Cheers,
    Rob
[reply]
[d/l]

In Section Seekers of Perl Wisdom