The test
check_vsprintf ("+01,234,567 :", "%0+ -'13.10Pd:", (mpfr_prec_t) 1234567);
is based on the output from glibc up to 2.36, which is incorrect:
https://sourceware.org/bugzilla/show_bug.cgi?id=23432
The GNU C Library has apparently been partially fixed in its Git
repository for the future 2.37, since a tsprintf failure has been
reported (this is a bug in this test, not in the MPFR library):
https://sympa.inria.fr/sympa/arc/mpfr/2023-01/msg00001.html
So, modified the test to avoid the particular case of leading zeros
due to the precision field larger than the number of digits. This
case has already been tested without the thousands separator (where
there are no issues with the C libraries), so that we do not miss
much testing. Added a comment explaining the issue and a possible
solution for future testing of this particular case (if need be).
Hello, At commit : https://github.com/qca/open-ath9k-htc-firmware/commit/e888634a85e7e4e3197b42ab3daa33de5c1744fd Building the toolchain fails at the mpfr-4.1.0 compilation stage (test for check_vsprintf) on my Gentoo system (gcc 14.2.1 / glibc 2.39 / binutils 2.42) ; for some reason, if I use Debian 8/9/10/11, no problem.
Anyway, I bumped myself mpfr to 4.2.1 since It has been fixed in 4.2.1 release and now mpfr builds fine. (And everything else too :) )
Maybe a patch can be made for 4.1.0 or else maybe bumping the release to 4.2.1.
https://gitlab.inria.fr/mpfr/mpfr/-/blob/4.2.1/ChangeLog