I'm trying to compile a custom module to include in a PerlApp executable. I'm using Visual Studio 2008 to compile the module. The resulting executable will not run on XP machines that do not have the compiler suite installed (a dependency seems to be generated on a C runtime library). Can you tell me what compiler toolchain I should be using to compile the module so I don't generate extra dependencies in the PerlApp executable?
For 32-bit work, the recommended compilers for building extensions are VC6 and MinGW. nmake from VC6, the free nmake15 download, or dmake (for MinGW) all work as the make tool.
ActivePerl is still compiled with VC6 because VC6 is the last VC version that produces code that links against MSVCRT.dll, and MSVCRT.dll is the only runtime which is a standard part of Windows (and not part of a particular C compiler release). The free GCC compiler from MinGW also uses this same runtime library.
This has advantages for deployment tools like PerlApp, Perl2exe and PAR (and most of the rest of the PDK) in that they don't need to bundle MSVCR70.dll, or MSVCR71.dll, or MSVCR80.dll, or MSVCR90.dll etc into their generated executables; MSVCRT.dll is already guaranteed to be on absolutely every Windows machine.
For most extensions, there should be no problem if you build them with a later VC version, but if you use such a module with PerlApp/Perl2exe/PAR then you will need to package and auto-extract the additional runtime libraries for those compilers too. It is of course possible to mix and match multiple runtime libraries, but due to incomplete macro redefinitions in the Perl headers, that can run into problems in certain cases.
For 64-bit work, the recommended compiler is the VC compiler from the Windows 2003 Platform SDK. The 32-bit or 64-bit versions of nmake from this SDK, or the nmake from VC6 will work.
Once again, we use this SDK because it uses the 64-bit version of MSVCRT.dll that ships with all 64-bit versions of Windows. This has the same benefits for 64-bit users that using the standard MSVCRT.dll has for 32-bit users. As with 32-bit, you can use a newer compiler, but you will then have to include the matching C runtime (and keep in mind that Microsoft does have a right to attach conditions to redistribution of their libraries).
The make tools tend to be more of a problem with 64-bit. The old standard, nmake15, is only a 16-bit binary so it's not usable on 64-bit systems. nmake from VC6 isn't free, and the only way to get the nmake tools from the 2003 SDK is to download the entire massive SDK.
When building modules for use with PerlApp, your treatment of third party libraries is also very important.
Common practice when building a dll (or a sofile or dylib on other operating systems) is to dynamically link the new library for the module to the third party libraries installed on the system. This keeps the files small, avoids legal liabilities, and reduces the amount of maintenance needed on your Perl module. Most non-ActiveState PPM repositories build modules with dynamic linking. However, when dynamic linking is used, and the result is wrapped with PerlApp, the target system's dynamic loader will be called upon to find the third party library. Unless the library is present on the target system in a place where the dynamic loader can find it, your wrapped executable will fail. If the target system has an incompatible version of the third party library available to the dynamic loader, the results can be unpredictable. Binding the desired version of the third party library into your wrapped executable will have no effect, unless the dynamic loader somehow knows where that library will be extracted.
For use with PerlApp, it is desirable that modules be built with static linking. The modules in ActiveState's PPM repositories are built with static linking. Static linking embeds the third party library into the new dll, and makes the application using it truly portable. On the other hand, using static linking places legal onus on you to ensure that you have permission from the owner of the third party library to embed, and thereby redistribute, their intellectual property. In some cases, the reason a module is *not* available in PPM is that the license terms of the required third party libraries are unacceptable to us, or simply do not allow redistribution. Make sure you do your homework to understand the restrictions and conditions attached to the use of any necessary third party libraries before you create modules with static linking.