"Jan Dubois" (j...@activestate.com) writes: > It's not the police, it's those that must not be named that you should > really be afraid off!
N'drangheta? > In you special case, which only works for one particular compiler version > anyways, and which you probably won't publish to CPAN either, this is > not really an issue. Well, Win32::SqlServer is on CPAN. > Nothing wrong, but typically pointless. Since Perl itself is already > already linking against MSVCRT.dll anyways, there is normally not much > point in bringing in another copy of the C RTL statically linked against > just a single extension. It shouldn't hurt though, beyond the general > issue of mixing C RTL you may already have because you compile with > a different compiler than your Perl itself was compiled with. Originally, I did not link with the DLL, but included it separately in the binary distribution. The install script for ActivePerl would copy the DLL to the same directory as the main DLL. But then a user reported that he could not use my module from IIS. For this to work, the DLL apparently must be in System32. The advice I got from Microsoft C++ MVPs was to use /MT to link statically. > I notice though that (at least with Perl 5.12.2) xsubpp will throw in > a -MD compiler option later on the commandline anyways, canceling any > effect your -MT might have had. So that is a good reason to use CCFLAGS to prevent that. -- Erland Sommarskog, Stockholm, esq...@sommarskog.se
