Feature Request: Update mpfr and mpc libraries to latest version for perl-5.38

[sisyphus]

Feel free to update in time for 5.34 and/or 5.36 - though I have no counter to the "Geez mate - it's a bit late for that, now !!" argument.

The mpfr library is now at version 4.2.0 (SP ships with 4.0.2) and mpc is at 1.3.1 (SP ships with 1.1.0, IIRC). The later versions provide some extra functionality, as well as bug fixes. As far as I'm aware, updating will be as simple as providing the latest sources to the current building process. There have been no changes to the configure and build requirements.

Cheers, Rob

[shawnlaffan]

Sounds doable to me. I'll have a go in the next few days.

(I'll also transfer this to the extlibs issue tracker as that is where these builds are handled).

[shawnlaffan]

Or perhaps sooner.

All works. We get one failing test for MPFR.

...
PASS: tsinu.exe
FAIL: tsprintf.exe
PASS: tsqr.exe
...

I have not checked if this was also the case for the previous version.

@sisyphus - is this test likely to affect perl usages?

[shawnlaffan]

The mpfr 4.0.2 build passes that test (and all others).

[sisyphus]

@sisyphus - is this test likely to affect perl usages?

I'm fairly confident it won't affect perl usages, but I should probably at least make some attempt to find out a bit more about the failure before making that assertion. AFAIK, the only modules that use the mpfr library are either maintained by me or depend on modules that are maintained by me - so any bad affect is going to come back on me, anyway.

I don't get any test failures with static builds of mpfr-4.2.0 using 64-bit 10.3.0, 11.3.0 or 12.2.0.

@shawnlaffan, could you post the contents of mpfr-4.2.0/tests/test-suite.log ... if it still exists. That might tell us a bit more about the failure.

Is there any mention of USE_MINGW_ANSI_STDIO in the Configure arguments given to SP's gmp build ? If not, then that might be relevant to the failure, as the formatting would then involve the msvc runtime library. And I would recommend that, in future, SP build gmp with -D__USE_MINGW_ANSI_STDIO. I actually configure the compiler to be gcc -DUSE_MINGW_ANSI_STDIO, just to ensure that -D__USE_MINGW_ANSI_STDIO is invoked every time that gcc is called. However, specifying -D__USE_MINGW_ANSI_STDIO as part of CFLAGS might be the more usual approach, and might work just as well.

Cheers, Rob

[shawnlaffan]

Here is the test log:

======================================
   MPFR 4.2.0: tests/test-suite.log
======================================

# TOTAL: 197
# PASS:  196
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tsprintf
==============

Error in mpfr_vsprintf (s, "%a", ...);
expected: "-0x1.400000p+0"
got:      "-0xap-3"
FAIL tsprintf.exe (exit status: 1)

GMP is built using standard flags.

https://github.com/StrawberryPerl/build-extlibs/blob/26d32e369209a828c42dadf7225ee7f034bd7f45/build.sh#L1686-L1697

[shawnlaffan]

And for completeness, mpfr is built using: https://github.com/StrawberryPerl/build-extlibs/blob/26d32e369209a828c42dadf7225ee7f034bd7f45/build.sh#L548-L559

[sisyphus]

Error in mpfr_vsprintf (s, "%a", ...); expected: "-0x1.400000p+0" got: "-0xap-3" FAIL tsprintf.exe (exit status: 1)

I think we can ignore that - it's just two different (but equivalent) hex representations of -1.25

Perl, itself, is ambivalent here. On my Windows builds of perl-5.36.0, if nvtype is double, I see:

D:\>perl -e "printf '%a', -1.25;"
-0x1.4p+0

But on the long double and quadmath builds:

D:\>perl -e "printf '%a', -1.25;"
-0xap-3

AFAICS, although the mpfr-4.0.2 version tsprintf.c does test formatting of -1.25, it doesn't run the "%a" test that is failing for you on mpfr-4.2.0. I'm happy to run with the belief that the difference we're seeing is explained by the absence of -D__USE_MINGW_ANSI_STDIO on your build of gmp - but the validity of that belief is unverified, and probably not all that important. (I don't even have a proven example of where it makes a difference wrt recent msvc runtimes.)

I initially thought that the sp536_20230311 build of gmp was up to date ... but I now realize that 6.1.2 and 6.2.1 are not the same thing ;-( I'm happy enough for that update to be put off until 5.38, as gmp-6.2.1 doesn't provide any additional functionality. (Just some performance improvements and perhaps the odd bugfix, AFAIK.) And if you update the static build of gmp, the static mpfr and mpc libraries should probably be rebuilt. (That could all wait for a bit, if you like.)

Cheers, Rob

[shawnlaffan]

Thanks Rob.

We can ignore that issue then.

If you want to have a go with the binaries then see: https://github.com/StrawberryPerl/build-extlibs/releases/download/dev_gcc10.3_20230313/64bit_mpc-1.3.1-bin_20230315.zip https://github.com/StrawberryPerl/build-extlibs/releases/download/dev_gcc10.3_20230313/64bit_mpfr-4.2.0-bin_20230315.zip

WRT GMP, it should already be at 6.2.1 in the 5.36 builds.
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/a1e125ea0c8886d041f719040703d7977521c63b/share/64bit-5.36.0.1.pp#L46

The full set of binaries in use at the moment are at https://github.com/StrawberryPerl/build-extlibs/releases/tag/dev_gcc10.3_20230313 if you want to check.

[sisyphus]

WRT GMP, it should already be at 6.2.1 in the 5.36 builds

Indeed. Sorry, my mistake. Thanks for your efforts Shawn - both for your efforts in general, but especially in relation to this issue. I'll now close it as completed. (I'll also update my sp536_20230311 installation with the updated mpc and mpfr libraries, and re-open if anything untoward crops up.)

Cheers, Rob

[shawnlaffan]

Not a problem Rob.