in reply to Re: Free MSVC tools + Activestate to compile CPAN Modules
in thread Free MSVC tools + Activestate to compile CPAN Modules

If you compile modules, you might need the same version of the compiler perl was compiled (if you use the Activestate-binary, I think you need VisualC6

That kind of thinking is what prevented me from trying this in the first place. Do you have any proof that purchasing and using VC6 is any different from using the free VC Toolkit I mention above when compiling using the ActiveState build? (not a rhetorical question, I'd like to know). So far I have not found any modules that don't work with the free version.

Well, with the free nmake you can compile a lot of cpan-modules

Strictly speaking, that isn't true. You can *install* non-XS modules with just nmake.exe but you need a compiler to *compile* XS modules. Nmake.exe comes included in the free SDK mentioned above so there is no need to download it separately. But you're right that nmake.exe by itself is useful for installing non-XS modules for those who don't want to or can't download the the full compiler.

  • Comment on Re^2: Free MSVC tools + Activestate to compile CPAN Modules

Replies are listed 'Best First'.
Re^3: Free MSVC tools + Activestate to compile CPAN Modules
by shay (Beadle) on Sep 01, 2004 at 12:43 UTC
    Generally you do need to use the same compiler to build CPAN modules as was used to build Perl.

    Upto version 6 of MSVC++ you can probably get away with using different versions: linking against msvcrt.lib always produced binaries depending on msvcrt.dll, which ships with the OS.

    However, from version 7 onwards (and the free toolkit is version 7) linking against msvcrt.lib now produces binaries depending on msvcr71.dll (or whatever the latest version is).

    ActivePerl is built using MSVC6, so if you build a module using the free tollkit then perl.exe will load msvcrt.dll and the module's DLL will load msvcr71.dll. If any CRT resources (e.g. file descriptors) are passed between the two then you'll have problems.

    I recently discovered this with one of my CPAN modules (Win32-UTCFileTime-1.32). I was able to fix it (in 1.33) by falling back to an OS-level filehandle if the passing of the CRT file descriptor failed. However, another of my modules (Win32-SharedFileOpen) definitely does not work with ActivePerl if built using the free toolkit -- it does much more passing around of CRT resources and can't be fixed as easily. The solution is either to build it with MSVC6, or rebuild Perl using the same compiler as is being used to build the module.

    Microsoft have a brief note about the perils of loading two different CRT DLL's at this URL (at the time of writing!):

    - Steve