Re: gcc for building Perl on WinXP
Hi Rob, Just getting to it now. (I know Chris has already established that the pthreads suport builds fine using his small patch to pthread.h. I'm building PDL-2.4.9_009, also with pthreads support as provided by 2), above - and also with Chris's amendment to pthread.h.) First thing I noticed with this Strawberry distro is that, as with most (all ?) Strawberry distros, there's no gfortran compiler. This means that the Slatec and Minuit parts of PDL won't get built. That's old news, and not all that critical - but I thought I should mention it anyway ;-) I know about that :) Apart from: http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip We have also prepared other PDL handy stuff - like: http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_2001.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_gsl-1.15-bin_2004.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_fftw-2.1.5-bin_20110506.zip It is only about decision how fat should strawberry perl be. Anyway you can unzip them into one directory and have a go. Apart from that, all looks good Unrelated to PDL, but the latest mpfr library (version 3.1.0) should build with TLS (Thread Local Storage) by default and straight out of the box. The version of the mpfr library that ships with Strawberry (version 3.0.1) was not built with TLS - which probably means that you didn't ask for it (--enable-TLS) when building the library. Mind you, I haven't checked that --enable-TLS will work for mpfr-3.0.1 on Windows, but 3.1.0 certainly provided TLS for me ... and without my asking.) No big deal - just thought I'd mention. On threaded perls, that TLS capability can be handy for Math::MPFR. Thanks for this notice, I will try to use --enable-TLS by the next mpfr-3.1+ rebuild (according ./configure --help it seems not to be available in 3.0.1). I noticed, too, that the mpc library that ships with Strawberry hasn't been built to accommodate the complex.h types (double _Complex and long double _Complex). From a perl point of view, this hardly matters at all because there's no way to natively pass these types to or from perl. I did slap together a Math::Complex_C module that wraps the complex.h types and functions, and thereby provides a gateway to passing these types to Math::MPC, but I doubt that anyone makes use of this capability anyway. Besides, Math::Complex_C can sometimes fail a test or two, generally because of compiler bugs (mainly in the form of incorrectly implemented functions). To enable this should I pass some extra option to mpc configure/make? -- kmx
Re: gcc for building Perl on WinXP
- Original Message - From: kmx Apart from: http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip We have also prepared other PDL handy stuff - like: http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_2001.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_gsl-1.15-bin_2004.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_fftw-2.1.5-bin_20110506.zip It is only about decision how fat should strawberry perl be. Yes - and making those additional drop-in zips available is probably a fair compromise. I don't think I've ever seen anyone other than me raise this matter, so demand for this support can't be all that high :-) I'll grab and install those additional bits and try them out next time I build PDL with Strawberry. (I'm sure they're fine - there's absolutely no reason to expect otherwise.) On threaded perls, that TLS capability can be handy for Math::MPFR. Thanks for this notice, I will try to use --enable-TLS by the next mpfr-3.1+ rebuild (according ./configure --help it seems not to be available in 3.0.1). With 3.1+ TLS should be built in without any need for being requested. If it doesn't happen, it means that the compiler has been found to *not* support TLS - but both my mingw64.sf 4.7.0 cross-compiler and mingw.org 4.5.2 compiler do provide the necessary bits. Mingw.org's 3.4.5 compiler apparently did not. So, I'm guessing (and it is only a guess) that the Strawberry compilers will provide TLS as well. If it gives you trouble you can, of course, still --disable-TLS. I *think* the 3.1.0 release notes implied that the --enable-TLS option was valid for the 3.0* versions of the mpfr library, but I never tried it out and I could be wrong. I wasn't even expecting 3.1.0 to build with TLS support, and was pleasantly surprised when it did :-) I noticed, too, that the mpc library that ships with Strawberry hasn't been built to accommodate the complex.h types (double _Complex and long double _Complex). To enable this should I pass some extra option to mpc configure/make? No - the problem is a bug in mpc.h. The expectation is that if a there's a suitable complex.h available, then the symbol _COMPLEX_H will be defined, but this is wrong since many complex.h versions (including mingw) don't define that symbol. I hacked my compiler's complex.h to define that symbol, and that worked fine - but many would consider that to be the *wrong* hack. Here's the offending piece of code in mpc.h: /* Check if complex.h is included */ #if defined (_COMPLEX_H) # define _MPC_H_HAVE_COMPLEX 1 #endif I guess you might prefer to change *it* instead of altering your compiler's complex.h. The fix on the svn repo has mpc.h check that _Complex_I is defined, so changing the first line of the above code to #if defined(_Complex_I) should work for you. In any case, there should be no such issue with the next release of mpc. Cheers, Rob
