is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry
Perl 5.18.x series ?
I have done some testing with PDL guys approx a year ago on 5.16.0 (I
Rob is also subscribed to this list) and AFAIK it works.
I've been testing it continually over the last year or so. Every module I
build (not just PDL), I've been building on USE_64_BIT_INT - for both 5.16.0
and current blead (5.17.x).
I haven't struck any problems at any time that were related to the 64int
I can think of only one con:
ActivePerl binaries (ppm packages) will not be usable on the 64int
architecture Strawberry Perl - unless, of course, ActiveState also start
providing packages for the 64int architecture. (I've no idea what
ActiveState are planning to do in this regard.)
I doubt that many Strawberry users (if any) would be affected by this, and I
don't regard it as a stopper. (Will 32int Strawberry builds still be
available for anyone who wants one ?)
As regards the ppm packages that I provide, they'll be available for both
the 64int and 32int architectures.
1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin
without any special hacking that was needed for 5.16.0
2/ PDL users are gonna like it
3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit
4/ Couple of others asking me privately will appreciate it (they ask: why
32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?)
One other thing to consider with 5.18 Strawberry is whether it should be
COW-enabled or not.
Until recently, the p5p plan was to make 5.18 COW-enabled, but that has now
been postponed to 5.20 (which will definitely be COW-enabled).
As the plan currently stands, 5.18 will build as COW-disabled by default -
but there's an option to build it COW-enabled (which p5p are encouraging
module authors to use - mainly to have them avoid rude shocks when 5.20 does
I guess Strawberry Perl would just go with the default option - though I
don't have any personal preference in either direction.