Front page | perl.perl5.porters |
Postings from September 2014
As recently mentioned in a thread on op/infnan.t & op/sprintf2.t failures on Windows, I'm now trying to add USE_LONG_DOUBLE support to MinGW builds on Windows. The attached patch is what I've got so far. I think it's very close, but the build falls over with an "Invalid version format" error when running write_buildcustomize.pl, which is very likely due to trouble with the twiddling of the NV_* config.h settings. (jhi confirmed it's a common symptom of messing up the floating point routines stringify/numify.) I originally forgot to change NVTYPE and NVSIZE at all. The build actually got further then -- all the way down to building the POSIX extension. I believe they're now set correctly (double / 8 normally; long double / 12 for USE_LONG DOUBLE builds), but ironically the build now fails much sooner. I wonder if the problem lies in the twiddling of these settings: NV_PRESERVES_UV NV_PRESERVES_UV_BITS NV_OVERFLOWS_INTEGERS_AT The first two are normally define / 32, but change to undef / 53 for 64-bit-int builds. My guess is that for USE_LONG_DOUBLE builds they should be define / 32 for 32-bit-int and define / 64 for 64-bit-int builds. Is that correct? (That's what I've done in the patch which so far isn't working, but maybe due to something else being wrong?) What about NV_OVERFLOWS_INTEGERS_AT? That's currently set to 256.0*256.0*256.0*256.0*256.0*256.0*2.0*2.0*2.0*2.0*2.0 for both 32-bit-int and 64-bit-int builds (which slightly surprised me -- should it be different for those two builds?). All those 256s and 2s make a total of 53 bits, matching NV_PRESERVES_UV_BITS for 64-bit-int builds(?!). Should that be different for USE_LONG_DOUBLE builds? ... And/or: Can anyone think of anything else that needs changing for USE_LONG_DOUBLE builds which I've overlooked in my patch?Thread Next