----- Original Message ----- From: "Jan Dubois" <[email protected]> > > I'll eventually take a look at this, but for now have considered mingw-w64 > to be too experimental to spend any time on it.
Yes, until recently I have also felt them to be "too experimental" - but they've become much more solid in the last few months. > Note that you always had access to a free 64-bit compiler by downloading > the Windows 2003 R2 Platform SDK (hich actually is even the compiler used > to build ActivePerl 64-bit itself, due to it linking to the 64-bit version > of MSVCRT.dll and not a compiler version specific one like MSVCR80.dll). Yes, I acknowledged that (in a roundabout way) a little further on in my post. I have that compiler and have been using it for quite some time with good results. IIRC (and I may be wrong here as I haven't checked recently), the trouble is that I can't get it to build some of the third party libraries that I play around with - nor can I get it to link to those libraries if they've been built with mingw64. So, I think there's a niche there for the mingw64/ActivePerl combo. > > I'm fine with making the modules as flexible as possible, even though > the PPM package for MinGW will most likely choose the smaller package, > which I assume has the more standard names. > I think that's the way to go - and it's the path that Strawberry Perl have chosen. It's a much smaller download (~50Mb versus ~200Mb). Not sure if it comes with gfortran, but I would think it lacks java, ada and other stuff - none of which is necessary anyway. (Having gfortran might be handy - though all of the fortran stuff in perl extensions still seems to need g77, which is unavailable with gcc-4.x.x.) > > Don't forget that I do have commit access to ExtUtils::MakeMaker too: > > http://www.mail-archive.com/[email protected]/msg02880.html > > I just don't want to commit anything that will need to be reverted or > fixed in a short while, so I'm waiting until we have figured out exactly > how this should work. Good - I think the Config.pm changes are ok but there's one thing in the MM_Win32.pm patch that's very worthy of caution - namely the messing around with "$self->{PERL_ARCHIVE}". It's there simply to force the compiler to link to the perl dll (as it can't link to perl5xx.lib). A better solution might be for ActiveState to supply a perl5xx.a. Now that Mark has verified that the glitches I've struck aren't inevitable, we conclude that I'm doing something wrong - and what better candidate is there than messing with PERL_ARCHIVE ? (I hope to sort that out today ... if I can just stop writing emails :-) > It is my goal to reduce the remaining local changes in modules bundled > by ActivePerl to the bare minimum necessary, and ideally to no changes > at all for any modules that are on CPAN and can therefore be updated > via PPM or any of the CPAN shells. Yes - I think I've been bitten in the past by having updated EU::MM on ActivePerl. I now make sure that I stick with the version of EU::MM that was shipped. Thanks Jan. Cheers, Rob _______________________________________________ Perl-Win32-Users mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
