----- Original Message ----- From: "Jan Dubois" < . . > > We link directly against perl58.dll. We have tested our current setup > with a large list of CPAN modules, and haven't found any that would > build with VC++ but not with MinGW.
Ok ... sounds good. My only doubt was that it seemed to me that both EU::MM and module authors assumed that an import lib would be available. Since an import lib is not, in fact, available I wondered if things might occasionally come unstuck. (I'm more than happy to believe that such occurrences will be either non-existent or rare.) >If you find any, please let me know > and we'll investigate how we can fix that. > Sounds like a challenge :-) First off I tried Inline::C, because that one can be a little curly ... but no joy there - it builds and performs fine. So, I tried PDL using a recent CVS source of that module - which builds fine on Win32 with either of the following: (1) MinGW-built perl (2) MSVC-built perl (using MSVC++ compiler) (3) MSVC-built perl (using MinGW compiler in conjunction with ExtUtils::FakeConfig) Building with MinGW/dmake and AS build 815 doesn't quite work, however. Compilation fails early on because an inappropriate 'pdl.h' gets created. It contains the line: typedef __int64 PDL_LongLong; whereas that line needs to be: typedef long long PDL_LongLong; There are probably other issues as well, but that one's the first that pops up. Anyway Jan, you can ignore that problem for the moment because: 1) It's a CVS release - not an official CPAN release. (The current PDL version on CPAN won't build under *any* flavour of Win32 perl.) 2) The problem might well be fixable from pdl.h.PL (which is run to generate 'pdl.h') - in which case it's something that can be attended to by the person who has undertaken to ensure that PDL builds on Win32 (ie me). 3) My assertion that it "builds fine on Win32" needs to be taken with a grain of salt. (There's a couple of niggling, though basically inconsequential, test failures under certain scenarios.) In all seriousness, I'll try to fix the problem by amending 'pdl.h.PL' when my mind is in a more lucid state - and if I find it's something that needs intervention on the part of ActiveState, then I'll get back to you. > However, there are lots of modules that don't compile on Windows at all, > even with VC++. They will most likely not compile with MinGW either, and > I'm not interested in hearing about those, as they are just not > compatible with Windows at all as far as I'm concerned and you should > talk to their authors instead. :) With many of the modules that fall into that category, the problem is fixable, and now one can fix and build those modules oneself using MinGW/dmake. In the past one had to wait for someone else (usually Randy Kobes) to build a ppm of any "buildable" module that failed ActiveState's automated ppm-build procedure. Well ... I guess most will still wait for Randy (or someone else) to fix any problems and provide a ppm - but at least AS have now provided an option - and full marks for doing that. > I still recommend to compile modules with VC++ 6.0 instead of MinGW if > you own a copy of VC++ 6.0, as the compiler is faster *and* generates > faster code (at least the last time I checked; I haven't been running > benchmarks lately). I think you'll find that there's not a lot in it. I'm quite happy to endorse the statement that, in general, if you are running AS perl then you should "compile modules with VC++ 6.0 instead of MinGW if you own a copy of VC++ 6.0", but don't let that deter you from using MinGW/dmake with AS perl if you don't have VC++ 6.0. The performance hit will be negligible if, indeed, it's even measurable. Cheers, Rob _______________________________________________ Perl-Win32-Users mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
