On 22/09/2025 20:06, Sam James wrote:
Pádraig Brady <[email protected]> writes:
On 22/09/2025 19:39, Sam James wrote:
Hi,
We had a report downstream in Gentoo at
https://bugs.gentoo.org/959467
of a build failure for coreutils when pasisng -mno-pclmul.
Ionen's analysis on the bug seems good to me, so quoting that:
"""
Haven't looked all that in-depth, but I wonder why src/cksum.c checks for
gnulib's GL_CRC_X86_64_PCLMUL at all, and also why it manages to be set?
cksum.c checks GL_CRC_X86_64_PCLMUL only so it prints appropriate --debug info.
You could remove the "|| GL_CRC_X86_64_PCLMUL" clause and just loose that minor
feature with `cksum -a crc32b`
Ah, thanks. Done that then in the workaround downstream.
coreutils own's pclmul check to set USE_PCLMUL_CRC32 does:
ac_save_CFLAGS=$CFLAGS
CFLAGS="-mavx -mpclmul $CFLAGS"
CFLAGS here has -mno-pclmul and comes after -mpclmul, so as
expected:
checking if vmull intrinsic exists... no
checking if pclmul intrinsic exists... no
checking if avx2 pclmul intrinsic exists... no
checking if avx512 pclmul intrinsic exists... no
But then there is another (lone) check, done by gnulib's
m4/crc-x86_64.m4 which pass for some reason (despite i686 and
-mno-pclmul) and sets GL_CRC_X86_64_PCLMUL:
checking if pclmul intrinsic exists... yes
Well that should be fixed anyway.
Then pclmul_supported function has:
# if USE_PCLMUL_CRC32 || GL_CRC_X86_64_PCLMUL
And finally src/cksum_pclmul.c is only built if USE_PCLMUL_CRC32,
while GL_CRC_X86_64_PCLMUL builds lib/crc-x86_64-pclmul.c (I see it
in the build.log)
However crc-x86_64-pclmul.c does not define cksum_pclmul, and
pclmul_supported does not use anything from that crc-x86_64-pclmul.c
that I can see? I could be missing something but the simple fix may be
to just drop the "|| GL_CRC_X86_64_PCLMUL" check.
"""
I can reproduce it with e.g. coreutils-9.8 with:
I think you would have seen the same with coreutils-9.7
Yes, to be clear, we did. I was just mentioning it such as to say the
bug isn't obsolete ;)
$ ./configure CFLAGS="-march=westmere -mno-aes -mno-avx -mno-pclmul -O2 -pipe"
$ make
/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../x86_64-pc-linux-gnu/bin/ld:
src/cksum-cksum.o: in function `pclmul_supported':
cksum.c:(.text+0x2c6): undefined reference to `cksum_pclmul'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:11791: src/cksum] Error 1
Note the gl_cv_crc_pclmul and utils_cv_pclmul_intrinsic_exists configure vars
are higher level ways to configure this feature in the coreutils build.
Passing -mno-pclmul is natural for users, looking at autoconf cache
variables isn't for many, though I'll mention it as an option.
Actually the attached is probably better.
It would keep the --debug accurate,
while addressing the build failure.
cheers,
Padraig
From 7f23940a5fcb0f9eab242ae59d94440ecf119b92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <[email protected]>
Date: Mon, 22 Sep 2025 20:46:33 +0100
Subject: [PATCH] build: fix build failure with mismatched pclmul
* src/cksum.c (pclmul_supported): In the case where
gnulib has pclmul enabled but coreutils does not,
ensure we don't reference the coreutils pclmul function.
Addresses https://bugs.gnu.org/79491
---
src/cksum.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/cksum.c b/src/cksum.c
index 3e009febd..fba33f688 100644
--- a/src/cksum.c
+++ b/src/cksum.c
@@ -152,8 +152,10 @@ pclmul_supported (void)
(pclmul_enabled
? _("using pclmul hardware support")
: _("pclmul support not detected")));
+# if USE_PCLMUL_CRC32
if (pclmul_enabled)
return cksum_pclmul;
+# endif
# endif
return nullptr;
--
2.50.1
