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_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