On Sun, 18 Apr 2010, Sisyphus wrote:

[...]
 
> 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.

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.

Once it is sufficiently stable I'll generate a PPM package for one of
the builds and make it available similar to the current MinGW package;
maybe even replace the current 32-bit MinGW with the 32-bit version
of MinGW-W64 as well.  But that won't be happening for at least another
2 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).
 
> 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.)

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.
 
> 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 :-)

Don't forget that I do have commit access to ExtUtils::MakeMaker too:

    http://www.mail-archive.com/makema...@perl.org/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. 

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.

Cheers,
-Jan

_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Reply via email to