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

Reply via email to