| Store | Cart

Using mingw64 with x64 ActiveState builds.

From: Sisyphus <sisy...@optusnet.com.au>
Sun, 18 Apr 2010 23:50:12 +1000
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 ;-) 

Recent Messages in this Thread
Sisyphus Apr 18, 2010 01:50 pm
Mark Dootson Apr 18, 2010 02:36 pm
Sisyphus Apr 19, 2010 12:37 am
Jan Dubois Apr 18, 2010 05:55 pm
Sisyphus Apr 19, 2010 01:13 am
Messages in this thread