On Tue, 20 Jan 2009, David Cantrell wrote: > On Mon, Jan 19, 2009 at 03:35:17PM -0800, Jan Dubois wrote: > > > This would be trivial to change. ActivePerl already determines the > > value of $Config{cc} dynamically. It sets it to 'gcc' if cl.exe > > can't be found on the PATH but gcc.exe is there. > > Isn't that kinda dodgy? XS modules expect to be built with the same > toolchain as perl was, and the way they figure that out is by looking > at %Config. If you mix and match compilers, Bad Things can happen.
Yes, just changing $Config{cc} is kind of dodgy, but ActivePerl is actually reconfiguring the rest of the toolchain too. So $Config{ccflags}, $Config{ldflags} and so on are all changed to the correct values too. Both Visual C 6.0 and the MinGW GCC compiler link against the same C runtime library (MSVCRT.dll), so there are no problems there either. One difference between the compilers is that VC uses a somewhat unusual mechanism to layout bit fields inside structs, so ActivePerl adds the -mms-bitfields option to the ccflags if GCC is being used. I'm not aware of any problems using MinGW to build additional modules for ActivePerl. Feel free to play with it yourself; all you need to do is ppm install MinGW with any ActivePerl 5.8.8 or later and you should be able to build modules using GCC and dmake, e.g. by using the cpan shell: cpan Win32::UTCFileTime BTW, the same is true for ActivePerl on HP-UX and Solaris: while ActivePerl has been compiled with the vendor compilers on those platforms, it will switch all %Config settings to the correct values for GCC if the vendor compiler isn't found, but 'gcc' is on the PATH (there are no PPM packages for GCC on HP-UX or Solaris though; you have to install it the traditional way). Cheers, -Jan