bug#79491: coreutils build failure with -mno-pclmul

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