Front page | perl.perl5.porters |
Postings from July 2012
RE: MinGW test failure in op/taint.t
From: Steve Hay
July 9, 2012 01:25
RE: MinGW test failure in op/taint.t
Message ID: 1B32FF956ABF414C9BCE5E487A1497E70DC3F029@ukmail02.planit.group
kmx wrote on 2012-06-27:
> On 27.6.2012 10:39, Steve Hay wrote:
>> Regarding your previous description of mingw-w64's naming convention:
>> 1. mingw-w32-bin_i686-mingw_* = native 32bit compiler (32bit gcc
>> creating 32bit binaries) 2. mingw-w64-bin_x86_64-mingw_* = native
>> 64bit compiler (64bit gcc creating 64bit binaries) 3.
>> mingw-w64-bin_i686-mingw_* = cross compiler (32bit compiler creating
>> where is the native 64-bit compiler (2.) located?! That's the one
> which we're most interested in definitely supporting, but I don't see
> it other than in your own (much more sensibly named!) download at
> http://strawberryperl.com/package/kmx/64_gcctoolchain/. I only see the
> two 32-bit compilers (1. and 3.) on the mingw-w64.sf.net website.
> Unfortunately mingw-w64.sf.net project does not have anything like the
> official release tarballs. You can get either "automated builds"
> (outputs of some kind nightly builds produced by automated build bot)
> or "personal builds" (unofficial releases prepared by some of the
> project team member).
> You are right there is no "automated build" of native 64bit gcc compiler.
> I think that close to the release quality are rubenvb's builds:
> w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/re l
> for 64bit native compiler try one of the following:
> - x86_64-w64-mingw32-gcc-4.7.1-release-win64_rubenvb.7z
> - x86_64-w64-mingw32-gcc-4.7.0-release-win64_rubenvb.7z
> - x86_64-w64-mingw32-gcc-4.5.3-release-win64_rubenvb.7z
>> I'm also confused by the naming conventions within the two mingw-
>> w64.sf.net ZIP files that I've downloaded:
>> 1. mingw-w32-bin_i686-mingw_* contains i686-w64-mingw32-* : why the w64
>> in the directory name if this is the native 32-bit compiler? 3.
>> mingw-w64-bin_i686-mingw_* contains x86_64-w64-mingw32-*: why the
> i686 in the download name if this is the x86_64 cross-compiler?
> There are two things:
> 1/ ZIP naming convention (which has no strict rules and ever packager
> can set his/her own) 2/ gcc architecture triplets: mingw-w64.sf.net
> project uses - 'x86_64-w64-mingw32' + 'i686-w64-mingw32' and this
> values are strictly fixed by gcc project (directory names always
> follow the rule 2/)
Thank you for pointing me at the rubenvb builds; apologies for my slow reply to all this...
I've been trying out all the options and just wanted to post back here with what I've found.
For native 32-bit compilers I see three options: mingw.org, rubenvb's build of mingw-w64.sf.net, and Mark Dootson's build of the same, used in Strawberry Perl. They all have unprefixed binaries in bin\, headers in include\ and libraries in lib\ and build with WIN64=undef GCCCROSS=undef. The latter two also contain unprefixed binaries in i686-w64-mingw32\bin\, but there is no gcc.exe there, so we have to use the top-level bin\.
(There is one other option -- the automated build of mingw-w64.sf.net, but that seems somewhat anomalous, having prefixed binaries in bin\: there seems to be no way to easily build with that right now, and given three other excellent options I'm not going to worry about supporting it. It also has unprefixed binaries in i686-w64-mingw32\bin\, including gcc.exe, but setting CCHOME to i686-w64-mingw32 and trying to use that gcc.exe causes it to fail with a CreateProcess error, so that doesn't help.)
For native 64-bit compilers I see two options: rubenvb's build of mingw-w64.sf.net, and Mark Dootson's build of the same, used in Strawberry Perl. They both also have unprefixed binaries in bin\, headers in include\ and libraries in lib\ and build with WIN64=define GCCCROSS=undef. They also contain unprefixed binaries in x86_64-w64-mingw32\bin\, but there is no gcc.exe there, so we have to use the top-level bin\.
Finally, for 32-bit cross-compilers producing 64-bit binaries I see two options: the automated build of mingw-w64.sf.net and rubenvb's build of the same. They both have prefixed binaries in bin\, headers in x86_64-w64-mingw32\include\ and libraries in x86_64-w64-mingw32\lib\ and build with WIN64=define GCCCROSS=define. (They also have unprefixed binaries in x86_64-w64-mingw32\bin\, including gcc.exe, but as with the automated build of the native 32-bit compiler they cause a CreateProcess error if those gcc's are used with CCHOME set to x86_64-w64-mingw32.)
As noted elsewhere, the mingw\ sub-directory doesn't always exist (in fact, only the two automated builds, one 32-bit and one cross-compiler, have it) and when it does it's just a copy of i686-w64-mingw32\ or x86_64-w64-mingw32\, so the latter must be used rather than mingw\ when setting CCINCDIR and CCLIBDIR.
As also noted elsewhere, for the cross-compilers the 64-bit DLLs required to run the binaries produced are located in x86_64-w64-mingw32\lib\ rather than bin\, which, of course, contains the 32-bit DLLs used by the compiler binaries themselves, so the XCOPYs near the end of win32\makefile.mk needed to get op\taint.t to run need fixing up a little. (They are always found in bin\ for native compilers, though -- both 32-bit and 64-bit.)
I'm pushing the necessary fixes from my findings now.
With these changes and CCHOME always set to the top-level folder, the three 32-bit options build and test fine; the two 64-bit options build and test fine except for intermittent failure in dist/IO/t/cachepropagate-tcp.t; and the two cross-compile options build and test fine except for the same intermittent failure, plus failures in porting/dual-life.t, porting/podcheck.t and porting/utils.t from the automated compiler build.