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!): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp

- Steve