Hi,For quite some time, ActivePerl users have been able to use mingw32/dmake seamlessly with x86 builds of ActivePerl. Many here will already be aware of that. However, the same is not true of the x64 ActiveState builds - attempting to use mingw64/dmake with them fails.
One of the things with mingw64 is that there are 2 possible nomenclatures.If you download the builds made available by sezero, the various executables (gcc, g++, ar, dlltool, etc.) are named simply gcc.exe, g++.exe, ar.exe, dlltool.exe, etc. (as per usual).
But then there's sometimes [1] an additional distro (in the order of ~200Mb) available from the same vendor ( http://sourceforge.net/projects/mingw-w64/files/ ) where the names of all of those executables is prefixed with 'x86_64-w64-mingw32-'. This arises, apparently, from the fact that these binaries are created as a cross-compilation - and the compiler itself is referred to as a "cross-compiler". I don't understand that aspect very well .... what I do understand is that, whichever distro we use, it will be equally serviceable - for starters, both versions of the compiler will build perl-5.12.0 on windows.
Strawberry Perl have chosen to use sezero's builds - I've been getting good results with the cross-compiler and seem to prefer it (but for no good reason, afaict :-)
Anyway, the attached patches to lib/ExtUtils/MM_Win32 and lib/ActivePerl/Config.pm enable the x64 builds of ActivePerl to work with both of these mingw64 compilers (and dmake) ... but there's a catch .... there are still problems with using mingw64 with ActivePerl. Just build Inline::C and you'll see what I mean. If there's more than one section of C code in the Inline::C script (as is the case with some of the test scripts) then you'll get bizarre "load_file:%1 is not a valid Win32 application at ...." errors from DynaLoader from the subsequent sections. (Afaict, if there's only one section of C code, as is generally the case, then there's no problems with Inline::C).
However, it goes even further than Inline::C. I can successfully build, test, and install Math::GMPz, Math::GMPq and Math::GMPf on x64 build 1200 using mingw64 and dmake ... but if I try to load (use/require) more than one of those modules in the same script, the first loads ok but the other ones croak with that DynaLoader error. The order in which I try to load them doesn't matter - the first will succeed, the next will cause the fatal load error.
Other perl extensions seem to be ok ... eg, no such problems with Math::GMP, much to my chagrin. I really would like to know what's going on here. I think I had similar issues when I first tried building perl (32-bit) using the mingw port of gcc-4.x.x, but thankfully they went away as gcc-4.x.x matured. (Note that mingw64 is gcc-4.4.4.)
And there's no such problem with these mingw64 compilers if they're the compiler that actually built perl. It's just when I try to use these compilers with x64 builds of ActivePerl that the strange DynaLoader errors can eventuate.
So ... do I file a bugzilla bug report at ActiveState and provide those patches ? If mingw64 is ever going to work with the x64 builds of ActivePerl, then something like them will be needed. (If the descision to exclusively use sezero's builds was made, then those patches could be simplified - there's currently a fair amount of kludge in them just to accommodate the possibility of the 'x86_64-w64-mingw32-' prefix.)
Or do we decide that mingw64 will never work satisfactorily with the x64 builds of ActivePerl and just forget about it ? Or do we decide that, since the compiler that built the x64 ActivePerls is freely available (unlike the compiler that builds the x86 versions), then there's not even any need to have the x64 builds work with mingw64 ?
Previous experience tells me that, in any event, Schwern is unlikely to ever apply my MM_Win32.pm patch - but I think ActiveState now use their own version of ExtUtils::MakeMaker. (ActivePerl/Config.pm is, afaik, outside of Schwern's jurisdiction :-)
Cheers, Rob[1] These "other" distros used to be the norm, but they now seem to be available only spasmodically. I asked about this on the mingw64 mailing list a while back, and was told that there were temporary problems with these builds. (For some definition of "temporary", no doubt ;-)
MM_Win32.patch
Description: Binary data
Config.patch
Description: Binary data
_______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
