Front page | perl.perl5.porters |
Postings from October 2009
kmx and I are currently working out how to get a "64-bit Strawberry Perl" built for the 5.12.x versions and I've mentioned to him that I should bring the p5p people in. He's said I can do so, as he's not subscribed to the list himself. > I have followed the current discussion about MINGW Win/64-bit patch > provided by Tor Lillqvist and have some comments. > > 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. 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.) > 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. > > 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 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__ > > 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". > 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 --Curtis -- Curtis Jewell csjewell@cpan.org http://csjewell.dreamwidth.org/ perl@csjewell.fastmail.us http://csjewell.comyr.org/perl/ "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c Strawberry Perl for Windows betas: http://strawberryperl.com/beta/Thread Next