On Sat, 20 Nov 2010, Erland Sommarskog wrote: > Reini Urban (rur...@x-ray.at) writes: > > You are not allowed to overrride CCFLAGS and LIBS with simplier > > settings. > > Not allowed? You mean that I could be caught by the police? > That's scary!
It's not the police, it's those that must not be named that you should really be afraid off! > > You are compiling a perl extension, with perl headers so you have to > > use perl cflags and libs. > > OK, I can see the point with using the same CCFLAGS; I might have been > lucky with things working anyway. I realised that since I did not have > the default flags, I did not have /W3. Using /W3 resulted in quite a > few warnings for the 64-bit version. Need to look into that... > > Anyway, I'm beginning to suspect that the crucial define is -DWIN32, > which I guess I get for free with windows.h, and this is why it works Indeed, just replacing #include <windows.h> with #define WIN32 works just as well. > with this file. For the example I posted, windows.h as such is not > needed, but with Win32::SqlServer I believe I need it anwway. > > But LIBS? I need the libraries that DLL has references to, but not the > rest. (The full list of libraries make the command-line very verbose, > and which easily hides warnings generated during the build. You don't need to link against the default set, but it would be good practice. For example a Perl built with the 64-bit VC++ compiler from the Windows 2003 SP1 Pltform SDK will link against bufferoverflowU.lib in addition to all the other libs, and you will miss that if you don't include the standard set. 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. > > The usual practrice is to add defines to CCFLAGS (but never -MT) and > > libs to LIBS, but never replace it. > > What's wrong with -MT? 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. 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. Cheers, -Jan
