----- 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_20111101.zip
We have also prepared other PDL handy stuff - like:
http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_20111101.zip
http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_gsl-1.15-bin_20111104.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
