I believe you need to use the VC6 (not 7/.Net) compiler to compile modules to run under ActivePerl
While that's good advice, it generally doesn't matter. Win32::SharedFileOpen is the only module I (definitely) know of that will build on ActivePerl with VC6, but not VC7.0 (or later). As I understand it, the fact that VC7.0 (and later) uses a different runtime C library than ActivePerl, means that there's a potential for irreconcilable difficulties. (This is precisely what accounts for the failure re Win32::SharedFileOpen.) But such problems seem to arise very infrequently.
Of course, if one did want to build Win32::SharedFileOPen (or any other module) on ActivePerl using a freely available compiler then, assuming one has a recent ActivePerl, one could simply use MinGW (which does use the same C runtime as ActivePerl) and dmake (or nmake) - as MinGW and dmake/nmake now work seamlessly with ActivePerl.
For older versions of ActivePerl that don't have this seamless interface, you can still use MinGW and dmake/nmake so long as you install the latest ExtUtils::FakeConfig and set the perl5opt environment variable to -MConfig_m.
I might as well give Strawberry Perl a plug while I'm at it - since I'm getting set to jump on that bandwagon. It comes with its own compiler/make (MinGW/dmake) combo so there's no need to chase up anything. Just install PPM into your Strawberry Perl and you can then also install modules via ppm if you want.
Cheers,
Rob | [reply] |