Hi,
I use the sezero builds - like you for no good reason other than they
were the first I tried.
I build using ExtUtils::FakeConfig and my own Config_w64.pm
Inline builds OK for me with this setup - the only test failure is in
the taint tests. I've never figured out precisely why (taint tests
always fail - not just the ones in Inline) but have just assumed its
either PERL5OPT=-MConfig_w64 or the setting of @INC do in my
sitecustomize.pl
Anyhow, the differences between by build process and yours would appear
to be
I use sezero builds
I install ExtUtils::FakeConfig and ensure it creates libperl5xx.a during
the 'dmake install' step.
PERL5OPT=-MConfig_w64
My Config_w64 is attached - and should carry a warning that it may be
completely wrong. I think it should be fairly straightforward to amend
this to set gcc etc config values to the named values for your install.
You could then maybe see if this approach works and it would help in
tracking down your test failures.
Regards
Mark
On 18/04/2010 14:50, Sisyphus wrote:
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 ;-)
_______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
package Config_w64;
require ExtUtils::FakeConfig;
my $cc_p = ( ExtUtils::FakeConfig::find_program( 'gcc' ) )[0];
$cc_p || die "Unable to find compiler 'gcc'";
$cc_p =~ s/[\\\/]bin[\\\/]?$//;
my $dmake = ( ExtUtils::FakeConfig::find_program( 'dmake' ) )[1];
$dmake || die "Unable to find dmake";
my $CONFIGPERL = $Config::Config{prefix};
my($ccflags, $libs, $perllibs, $libperl, $archlib);
my $arch = $Config::Config{archname};
my $bperllib = $Config::Config{libperl};
$ccflags = ' -DNDEBUG -O2 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DCONSERVATIVE -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX';
$libs = ' -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt';
$perllibs = $libs;
if( ($bperllib eq 'perl58.lib') && ($arch eq 'MSWin32-x64-multi-thread' ) ){
# perl 5.8 x64
$ccflags .= ' -DWIN64 -DNO_HASH_SEED';
$libperl = 'libperl58.a';
$archlib = 'x86_64-w64-mingw32';
} elsif( ($bperllib eq 'perl510.lib') && ($arch eq 'MSWin32-x64-multi-thread' )
) {
# perl 5.10 x64
$ccflags .= ' -DWIN64';
$libperl = 'libperl510.a';
$archlib = 'x86_64-w64-mingw32';
} elsif( ($bperllib eq 'perl512.lib') && ($arch eq 'MSWin32-x64-multi-thread' )
) {
# perl 5.12 x64
$ccflags .= ' -DWIN64';
$libperl = 'libperl512.a';
$archlib = 'x86_64-w64-mingw32';
} elsif( ($bperllib eq 'perl58.lib') && ($arch eq 'MSWin32-x86-multi-thread' )
) {
# perl 5.8 x86
$ccflags .= ' -DNO_HASH_SEED';
$libperl = 'libperl58.a';
$archlib = 'i686-w64-mingw32';
} elsif( ($bperllib eq 'perl510.lib') && ($arch eq 'MSWin32-x86-multi-thread'
) ) {
# perl 5.10 x86
$libperl = 'libperl510.a';
$archlib = 'i686-w64-mingw32';
} elsif( ($bperllib eq 'perl512.lib') && ($arch eq 'MSWin32-x86-multi-thread'
) ) {
# perl 5.12 x86
$libperl = 'libperl512.a';
$archlib = 'i686-w64-mingw32';
} else {
die qq(Archname $arch and perllib $bperllib is not supported by Config_w64);
}
my %values = (
cc => 'gcc',
ccname => 'gcc',
ccflags => $ccflags,
_a => '.a',
_o => '.o',
ar => 'ar',
cpp => 'gcc -E',
libpth => qq(\"$cc_p\\lib\" \"$cc_p\\$archlib\\lib\"),
cppminus => '-',
cpprun => 'gcc -E',
cppstdin => 'gcc -E',
ld => 'g++',
lddlflags => qq(-s -mdll -L\"$CONFIGPERL\\lib\\CORE\"),
ldflags => qq(-s -L\"$CONFIGPERL\\lib\\CORE\"),
lib_ext => '.a',
libc => '-lmsvcrt',
libperl => $libperl,
make => $dmake,
nm => 'nm',
obj_ext => '.o',
libs => $libs,
perllibs => $perllibs,
);
eval 'use ExtUtils::FakeConfig %values';
1;
_______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
