GNU bug report logs - #79491
coreutils build failure with -mno-pclmul

Previous Next

To reply to this bug, email your comments to 79491 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> gentoo.org>
To: bug-coreutils <at> gnu.org
Subject: coreutils build failure with -mno-pclmul
Date: Mon, 22 Sep 2025 19:39:40 +0100

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?

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

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:
$ ./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

thanks,
sam

Message #8 received at 79491 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Sam James <sam <at> gentoo.org>, 79491 <at> debbugs.gnu.org
Subject: Re: bug#79491: coreutils build failure with -mno-pclmul
Date: Mon, 22 Sep 2025 19:56:40 +0100

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`
> 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
> $ ./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.

cheers,
Padraig

Message #11 received at 79491 <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> gentoo.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 79491 <at> debbugs.gnu.org
Subject: Re: bug#79491: coreutils build failure with -mno-pclmul
Date: Mon, 22 Sep 2025 20:06:12 +0100

Pádraig Brady <P <at> draigBrady.com> 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.

>
> cheers,
> Padraig

thanks,
sam

Message #14 received at 79491 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Sam James <sam <at> gentoo.org>
Cc: 79491 <at> debbugs.gnu.org
Subject: Re: bug#79491: coreutils build failure with -mno-pclmul
Date: Mon, 22 Sep 2025 20:49:41 +0100

[Message part 1 (text/plain, inline)]

On 22/09/2025 20:06, Sam James wrote:
> Pádraig Brady <P <at> draigBrady.com> 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

[coreutils-gnulib-pclmul-mismatch.patch (text/x-patch, attachment)]

Message #17 received at 79491 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Sam James <sam <at> gentoo.org>
Cc: 79491 <at> debbugs.gnu.org
Subject: Re: bug#79491: coreutils build failure with -mno-pclmul
Date: Mon, 22 Sep 2025 13:43:17 -0700

On 2025-09-22 12:49, Pádraig Brady wrote:
> Actually the attached is probably better.
> It would keep the --debug accurate,
> while addressing the build failure.

Although that looks like a win, I keep coming back to the question, why 
should Gnulib have pclmul enabled while coreutils does not? More 
generally, why does coreutils bother to check for whether pclmul is 
enabled? Can't it rely on Gnulib's determination?

Gnulib and coreutils check for pclmul slightly differently, but I don't 
see why there should be a difference.

Message #20 received at 79491 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Sam James <sam <at> gentoo.org>
Cc: 79491 <at> debbugs.gnu.org
Subject: Re: bug#79491: coreutils build failure with -mno-pclmul
Date: Tue, 23 Sep 2025 18:29:30 +0100

On 22/09/2025 21:43, Paul Eggert wrote:
> On 2025-09-22 12:49, Pádraig Brady wrote:
>> Actually the attached is probably better.
>> It would keep the --debug accurate,
>> while addressing the build failure.
> 
> Although that looks like a win,

I'll push that to fix the build failure at least.

> I keep coming back to the question, why
> should Gnulib have pclmul enabled while coreutils does not? More
> generally, why does coreutils bother to check for whether pclmul is
> enabled? Can't it rely on Gnulib's determination?
> 
> Gnulib and coreutils check for pclmul slightly differently, but I don't
> see why there should be a difference.

I agree. I admit I didn't look too much at
gnulib's build/runtime hardware detection,
but it would be good to consolidate/ make consistent.

cheers,
Padraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.