Created attachment 919368 [details] dev-libs/mpfr config.log I just updated my system and the only major change was to glibc. I tried to recompile my system against glibc 2.41 but first wanted to re-compile dev-libs/gmp, dev-libs/mpfr, and dev-libs/mpc. I get this error upon configure: checking for gmp.h... yes checking for recent GMP... yes checking usable gmp.h at link time... yes checking for GMP_NUMB_BITS and sizeof(mp_limb_t) consistency... no configure: error: GMP_NUMB_BITS and sizeof(mp_limb_t) are not consistent. You probably need to change some of the GMP or MPFR compile options. See 'config.log' for details (search for GMP_NUMB_BITS). I re-compiled gmp with simply "-O2 -pipe" but the error did not go away. config.log and emerge --info attached. Please help, this is pretty serious.
Created attachment 919369 [details] emerge --info
Re-compiling sys-libs/glibc with just "-O2 pipe" made mpfr get past the configure process, maybe LTO or something is broken with glibc 2.41. Another possible culprit is compiling glibc 2.41 with -march=x86-64-v3. flag-o-matic in the glibc ebuild already filters out -fwhole-program. Will test more soon.
I'm not sure that using -fwhole-program on libraries is correct. Anyway, yes, this is glibc-2.41, but it's glibc-2.41 *and* clang. There's a bunch of relevant commits at https://gitlab.inria.fr/mpfr/mpfr/-/commits/master.
The configure test failing is: ``` configure:18660: checking for GMP_NUMB_BITS and sizeof(mp_limb_t) consistency configure:18690: clang -o conftest -O3 -march=x86-64-v3 -fomit-frame-pointer -flto=thin -fno-stack-protector -fno-stack-clash-protection -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -pipe -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -O3 -march=x86-64-v3 -fomit-frame-pointer -flto=thin -fno-stack-protector -fno-stack-clash-protection -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -pipe -fuse-ld=lld -Wl,-z,lazy -Wl,--strip-all conftest.c >&5 In file included from conftest.c:58: In file included from /usr/include/stdio.h:437: /usr/include/bits/floatn.h:93:20: error: cannot combine with previous '__float128' declaration specifier 93 | typedef __float128 _Float128; | ^ conftest.c:53:19: note: expanded from macro '_Float128' 53 | #define _Float128 __float128 | ^ 1 error generated. configure:18690: $? = 1 ```
https://patchwork.yoctoproject.org/project/oe-core/patch/20250206163148.2719087-1-raj.khem@gmail.com/ https://sympa.inria.fr/sympa/arc/mpfr/2024-12/msg00001.html There were various patches after related to math.h and _Float* use in git. Please try to identify which are needed (rather than using the rejected patch in my first link).
I tried compiling MPFR from git, added math.h to configure.ac GMP_NUMB_BITS test, nothing is working. I removed the test from configure completely and then I get: /usr/include/bits/floatn.h:93:20: error: cannot combine with previous '__float128' Instantly as the build starts. I will simply add dev-libs/mpfr to package.env and have it build against GCC for now.
Hello, I've reproduced this failure and none of the existing mpfr upstream patches fix it. I created a glibc bug report which concluded that the problem is in mpfr: https://sourceware.org/bugzilla/show_bug.cgi?id=32750 Until mpfr maintainers fix it, my suggestion is to just use the Yocto patch as a workaround. Drop it when it's properly fixed upstream. Created a PR: https://github.com/gentoo/gentoo/pull/40865
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59d77345086feb6141a77a48f0dbb359c9979aff commit 59d77345086feb6141a77a48f0dbb359c9979aff Author: Adrian Ratiu <adrian.ratiu@collabora.com> AuthorDate: 2025-03-03 12:04:25 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-06 01:21:55 +0000 dev-libs/mpfr: add patch to workaround clang breakage Add a workaround patch used by Yocto to fix the clang breakage. This patch can be dropped once upstream mpfr fixes the breakage using one of the solutions proposed in the glibc bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=32750 Closes: https://bugs.gentoo.org/949962 Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Closes: https://github.com/gentoo/gentoo/pull/40865 Signed-off-by: Sam James <sam@gentoo.org> ...h.h-to-use-predefined-_Float128-definitio.patch | 48 ++++++++++++++++++++++ dev-libs/mpfr/mpfr-4.2.1.ebuild | 1 + 2 files changed, 49 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5a49b7729eb17f7c271b0f2cbf63a27b0df2d81 commit c5a49b7729eb17f7c271b0f2cbf63a27b0df2d81 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-03-07 12:50:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-07 12:52:07 +0000 Revert "dev-libs/mpfr: add patch to workaround clang breakage" This reverts commit 59d77345086feb6141a77a48f0dbb359c9979aff. It doesn't call eautoreconf despite modifying an autotools source file; I'm not going to worry about fixing that and instead just revert given upstream plan on making a patch release soon (see https://sourceware.org/bugzilla/show_bug.cgi?id=32750#c10). Bug: https://bugs.gentoo.org/949962 Signed-off-by: Sam James <sam@gentoo.org> ...h.h-to-use-predefined-_Float128-definitio.patch | 48 ---------------------- dev-libs/mpfr/mpfr-4.2.1.ebuild | 1 - 2 files changed, 49 deletions(-)
Created attachment 920334 [details, diff] Backported upstream patch I've backported manually upstream patch and also modifyed the configure script to use their new macro for float128 and at least it compiled without problems on clang with libc++ and compiler-rt defaulted on amd64 llvm profile. I am not sure if this might have any runtime troubles, I ask for a proper test.
Created attachment 920336 [details, diff] Manual upstream fix backport I've manually backported upstream fix for _Float128, deleted configure and manually regenerated with autoconf (this could be done by the ebuild?) and it seems to compile fine with llvm amd64 (libc++ and compiler-rt). Further tests are requested as I don't know if something is broken in runtime. Thanks.
(In reply to David Carlos Manuelda from comment #11) > I've manually backported upstream fix for _Float128, deleted configure and > manually regenerated with autoconf (this could be done by the ebuild?) Not for a critical package like mpfr because of circular dependencies. That's why I didn't Just Do It.
*** Bug 951366 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=474da63926134b9de1b85e3ff7fa13464c8aabea commit 474da63926134b9de1b85e3ff7fa13464c8aabea Author: Sam James <sam@gentoo.org> AuthorDate: 2025-03-21 02:47:49 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-21 02:47:49 +0000 dev-libs/mpfr: add 4.2.2 Bug: https://bugs.gentoo.org/923985 Closes: https://bugs.gentoo.org/949962 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/mpfr/Manifest | 2 + dev-libs/mpfr/mpfr-4.2.2.ebuild | 98 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+)
Thank you everyone!
