Re: Win32/mingw-w64 compilation of Perl (was Re: Noticed the 64-bit packs uploaded at r9797...)

From: "Curtis Jewell" <lists.perl.perl5-porters@csjewell.fastmail.us>

>> At the beginning I would like to clarify that currently we have in fact
>> 3 different MINGW compilers available:
>>
>> 1. "old MINGW" = 32-bit compiler from mingw.org project
>> 2. 32-bit compiler from mingw-w64.sf.net project (in fact competitor of
>> 1.)
>> 3. 64-bit compiler from mingw-w64.sf.net project
>> Note: Yes the case 2. sounds slightly confusing "32bit compiler by
>> mingw-w64" but it exists
>
> (explanation for p5p from me: #1, as far as Strawberry is concerned, is
> the current gcc-3.4.5 that Strawberry uses today, #2 and #3 are the
> gcc-4.4.3 prerelease binaries we're working with.

The version of #3 that I have reports itself as being version 4.5.0 
(experimental).
I'm getting the binary from http://sourceforge.net/projects/mingw-w64/files/ 
.
That link seems a bit dodgy - mostly it has binaries for both #2 and #3 
updated daily, as well as the source. Currently that page is showing me 
mingw-w64-src_20091026.tar.bz2 and some other stuff - but no binary builds 
are visible.

I've not tried using #2.

> I'm starting to write
> the capability to use all 3 into the Perl::Dist::* modules [see
> http://fisheye2.atlassian.com/changelog/cpan/?cs=9827&@csTruncateDiffs=false
> for the "3-way support"] , so we can migrate to gcc-4 built binaries for
> Strawberry, most likely for the April 2010 release if all goes well. #2
> is required because I'd really prefer to have a matching pair of
> compilers for the 32-bit and 64-bit builds. Easier support.)

If you build perl with #2, what does 'perl -V:ivsize' report ?
I'm guessing it will be 4, but imho we really want 8 (which is what we get 
when we build perl with #3). If it *is* 8, let me know and I'll start 
playing with it, too.

>> What I would like to propose is to patch perl core in a way that will
>> cover not only 64bit but also 32bit version of compiler from
>> mingw-w64.sf.net project. So in the end all 3 compilers from
>> "mingw-family" mentioned above to be supported.

Yes - that's what's needed. (Of course, we also probably shouldn't break 
Visual Studio and Borland builds in the process ;-)

>> The Tor's patch is based on 64-bit compiler from mingw-w64.sf.net
>> project; however it seems that it uses a cross-compiler (32-bit compiler
>> executable building 64-bit target). I have nothing against using cross
>> compiler but I think that the default build scripts/makefiles/etc.
>> included in perl core should prefer building the perl by native compiler
>> (64bit compiler for 64bit target; 32bit compiler for 32bit target) - in
>> that case the gcc will simply be gcc (not  x86_64-w64-mingw32-gcc) and
>> the same with other tools.

I, too, would prefer to be using something called 'gcc' instead of 
'x86_64-w64-mingw32-gcc', but I'm thinking there must be something being 
offered by #3 that's not available with #2.

>> I know that mingw-w64 project is still in pre-release phase and it is
>> not so easy to get the right binaries, but we (strawberry perl project)
>> asked mingw-w64 guys and they kindly provided up-to-date built of native
>> 32-bit and native 64-bit toolchain binaries (we temporarily store them
>> here http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/ ) -
>> before they release something better we can use these.
>>
>> The other comment I have generally regards #ifdef used in Tor's patch.
>> The main problem I see is that the patch uses #ifdef __MINGW64 ... but
>> AFAIK the right way to distinguish mingw-w64's 64bit compiler is to use
>> __MINGW64__

Aaah ... that sounds right.
I couldn't see what was going on there. Certainly, for me, __MINGW64 was not 
defined - so I worked around that problem by defining the symbol in the 
makefile.mk.
That enabled Tor's patches to work - but it now looks to me that the correct 
thing to do is to replace __MINGW64 with __MINGW64__, as you suggest. Then I 
can remove the -D__MINGW64 from my makefile.mk.

>> To sum up:
>> 1. 32-bit compiler from mingw.org project - defines __MINGW32__
>> 2. 32-bit compiler from mingw-w64.sf.net - defines __MINGW32__
>> 3. 64-bit compiler from mingw-w64.sf.net - defines both __MINGW32__ and
>> __MINGW64__
>>
>> If you will agree with supporting also 32-bit toolchain from
>> mingw-w64.sf.net project we have to fix the following two issues:
>>
>> Tor's patch makes the following change:
>> --- a/ext/threads/threads.xs
>> +++ b/ext/threads/threads.xs
>> @@ -5,7 +5,7 @@
>>  /* Workaround for XSUB.h bug under WIN32 */
>>  #ifdef WIN32
>>  #  undef setjmp
>> -#  if !defined(__BORLANDC__)
>> +#  if !defined(__BORLANDC__) && !defined(__MINGW64)
>>  #    define setjmp(x) _setjmp(x)
>>  #  endif
>>  #endif
>>
>> Unfortunately this might work just for 64-bit compiler from
>> mingw-w64.sf.net however will throw an error with 32-bit compiler from
>> mingw-w64.sf.net. To be honest I do not know how to fix this as
>> extending patch like:
>>
>> -#  if !defined(__BORLANDC__)
>> +#  if !defined(__BORLANDC__) && !defined(__MINGW64__) &&
>> !defined(__MINGW32__)
>>
>> might work on 32-bit compiler by mingw-w64 but will probably fail on the
>> "old" 32-bit compiler from mingw.org. Unfortunately there is not a easy
>> way to distinguish 32-bit compiler by mingw-w64.sf.net from 32-bit
>> compiler by mingw.org as mingw-w64.sf.net project makes is "as
>> compatible as possible".

Why do #1 and #2 have different requirements ? Is it because #1 is version 
3.x.x and #2 is version 4.x.x ? (If so, then I guess we could make the 
distinction based on version numbers.)
I haven't checked on what __MINGW_EXTENSION is. I take it you can't make use 
of this in this instance (as you've done below).
>> Perhaps somebody can remember what was the reason for this "Workaround
>> for XSUB.h bug under WIN32".
>>
>> From pretty the same reason also this part of Tor patch is not friendly
>> to 32-compiler by mingw-w64.org
>>
>> --- a/win32/win32.c
>> +++ b/win32/win32.c
>> @@ -2014,7 +2014,7 @@ win32_uname(struct utsname *name)
>>      GetSystemInfo(&info);
>>
>>  #if (defined(__BORLANDC__)&&(__BORLANDC__<=0x520)) \
>> - || (defined(__MINGW32__) && !defined(_ANONYMOUS_UNION))
>> + || (defined(__MINGW32__) && !defined(_ANONYMOUS_UNION) &&
>> !defined(__MINGW64))
>>      procarch = info.u.s.wProcessorArchitecture;
>>  #else
>>      procarch = info.wProcessorArchitecture;
>>
>> Here I would propose changing the patch in this way:
>>
>> - || (defined(__MINGW32__) && !defined(_ANONYMOUS_UNION))
>> + || (defined(__MINGW32__) && !defined(_ANONYMOUS_UNION) &&
>> !defined(__MINGW_EXTENSION))
>>
>> this makes it work with both (32/64-bit) compiler from mingw-w64.sf.net

I'll give all of this (plus any other changes that develop in the meantime) 
a run for myself over the weekend when I have time.

Great to see a push for a 64-bit Strawberry Perl !!

Cheers,
Rob 

• Win32/mingw-w64 compilation of Perl (was Re: Noticed the 64-bit packsuploaded at r9797...) by Curtis Jewell
• Re: Win32/mingw-w64 compilation of Perl (was Re: Noticed the 64-bit packs uploaded at r9797...) by Sisyphus