GNU bug report logs -
#78562
Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin
Previous Next
To reply to this bug, email your comments to 78562 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Fri, 23 May 2025 13:21:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Dyballa <Peter_Dyballa <at> Web.DE>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Fri, 23 May 2025 13:21:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello!
The compile used is Clang, Apple LLVM version 10.0.0 (clang-1000.11.45.5). The CPU built into the Mac is Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz.
The error is:
mv -f src/blake2/.deps/cksum-b2sum.Tpo src/blake2/.deps/cksum-b2sum.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-crctab.o -MD -MP -MF src/.deps/cksum-crctab.Tpo -c -o src/cksum-crctab.o `test -f 'src/crctab.c' || echo './'`src/crctab.c
/usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx512bw -mavx512f -mvpclmulqdq -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/libcksum_avx512_a-cksum_avx512.o -MD -MP -MF src/.deps/libcksum_avx512_a-cksum_avx512.Tpo -c -o src/libcksum_avx512_a-cksum_avx512.o `test -f 'src/cksum_avx512.c' || echo './'`src/cksum_avx512.c
mv -f lib/.deps/libcoreutils_a-vasnprintf.Tpo lib/.deps/libcoreutils_a-vasnprintf.Po
/usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx -mpclmul -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/libcksum_pclmul_a-cksum_pclmul.o -MD -MP -MF src/.deps/libcksum_pclmul_a-cksum_pclmul.Tpo -c -o src/libcksum_pclmul_a-cksum_pclmul.o `test -f 'src/cksum_pclmul.c' || echo './'`src/cksum_pclmul.c
mv -f src/.deps/cksum-crctab.Tpo src/.deps/cksum-crctab.Po
src/cksum.c:190:30: error: invalid cpu feature string for builtin
bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
^ ~~~~~~~~~~~~
mv -f src/.deps/cksum-sum.Tpo src/.deps/cksum-sum.Po
1 error generated.
depbase=`echo src/comm.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
/usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/comm.o -MD -MP -MF $depbase.Tpo -c -o src/comm.o src/comm.c &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo src/cp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
/usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cp.o -MD -MP -MF $depbase.Tpo -c -o src/cp.o src/cp.c &&\
mv -f $depbase.Tpo $depbase.Po
make[2]: *** [src/cksum-cksum.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f src/.deps/cksum-digest.Tpo src/.deps/cksum-digest.Po
mv -f src/.deps/libcksum_pclmul_a-cksum_pclmul.Tpo src/.deps/libcksum_pclmul_a-cksum_pclmul.Po
mv -f src/.deps/libcksum_avx512_a-cksum_avx512.Tpo src/.deps/libcksum_avx512_a-cksum_avx512.Po
mv -f src/blake2/.deps/cksum-blake2b-ref.Tpo src/blake2/.deps/cksum-blake2b-ref.Po
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
First build started with "/usr/bin/make -j8 -w all", second build with "/usr/bin/make -w all" – same failure:
mv -f src/blake2/.deps/cksum-b2sum.Tpo src/blake2/.deps/cksum-b2sum.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-sum.o -MD -MP -MF src/.deps/cksum-sum.Tpo -c -o src/cksum-sum.o `test -f 'src/sum.c' || echo './'`src/sum.c
mv -f src/.deps/cksum-sum.Tpo src/.deps/cksum-sum.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-cksum.o -MD -MP -MF src/.deps/cksum-cksum.Tpo -c -o src/cksum-cksum.o `test -f 'src/cksum.c' || echo './'`src/cksum.c
src/cksum.c:190:30: error: invalid cpu feature string for builtin
bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
^ ~~~~~~~~~~~~
1 error generated.
make[2]: *** [src/cksum-cksum.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
make[1]: *** [all-recursive] Error 1
--
Greetings
Pete <]
o __o |__ o HPV, the real
___o /I -\<, |o \ -\),-% high speed!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Fri, 23 May 2025 23:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 23/05/2025 14:20, Peter Dyballa via GNU coreutils Bug Reports wrote:
> Hello!
>
> The compile used is Clang, Apple LLVM version 10.0.0 (clang-1000.11.45.5). The CPU built into the Mac is Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz.
>
> The error is:
>
> mv -f src/blake2/.deps/cksum-b2sum.Tpo src/blake2/.deps/cksum-b2sum.Po
> /usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-crctab.o -MD -MP -MF src/.deps/cksum-crctab.Tpo -c -o src/cksum-crctab.o `test -f 'src/crctab.c' || echo './'`src/crctab.c
> /usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx512bw -mavx512f -mvpclmulqdq -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/libcksum_avx512_a-cksum_avx512.o -MD -MP -MF src/.deps/libcksum_avx512_a-cksum_avx512.Tpo -c -o src/libcksum_avx512_a-cksum_avx512.o `test -f 'src/cksum_avx512.c' || echo './'`src/cksum_avx512.c
> mv -f lib/.deps/libcoreutils_a-vasnprintf.Tpo lib/.deps/libcoreutils_a-vasnprintf.Po
> /usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx -mpclmul -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/libcksum_pclmul_a-cksum_pclmul.o -MD -MP -MF src/.deps/libcksum_pclmul_a-cksum_pclmul.Tpo -c -o src/libcksum_pclmul_a-cksum_pclmul.o `test -f 'src/cksum_pclmul.c' || echo './'`src/cksum_pclmul.c
> mv -f src/.deps/cksum-crctab.Tpo src/.deps/cksum-crctab.Po
> src/cksum.c:190:30: error: invalid cpu feature string for builtin
> bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
> ^ ~~~~~~~~~~~~
> mv -f src/.deps/cksum-sum.Tpo src/.deps/cksum-sum.Po
> 1 error generated.
> depbase=`echo src/comm.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> /usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/comm.o -MD -MP -MF $depbase.Tpo -c -o src/comm.o src/comm.c &&\
> mv -f $depbase.Tpo $depbase.Po
> depbase=`echo src/cp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> /usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cp.o -MD -MP -MF $depbase.Tpo -c -o src/cp.o src/cp.c &&\
> mv -f $depbase.Tpo $depbase.Po
> make[2]: *** [src/cksum-cksum.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> mv -f src/.deps/cksum-digest.Tpo src/.deps/cksum-digest.Po
> mv -f src/.deps/libcksum_pclmul_a-cksum_pclmul.Tpo src/.deps/libcksum_pclmul_a-cksum_pclmul.Po
> mv -f src/.deps/libcksum_avx512_a-cksum_avx512.Tpo src/.deps/libcksum_avx512_a-cksum_avx512.Po
> mv -f src/blake2/.deps/cksum-blake2b-ref.Tpo src/blake2/.deps/cksum-blake2b-ref.Po
> make[2]: Leaving directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
>
>
> First build started with "/usr/bin/make -j8 -w all", second build with "/usr/bin/make -w all" – same failure:
>
> mv -f src/blake2/.deps/cksum-b2sum.Tpo src/blake2/.deps/cksum-b2sum.Po
> /usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-sum.o -MD -MP -MF src/.deps/cksum-sum.Tpo -c -o src/cksum-sum.o `test -f 'src/sum.c' || echo './'`src/sum.c
> mv -f src/.deps/cksum-sum.Tpo src/.deps/cksum-sum.Po
> /usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-cksum.o -MD -MP -MF src/.deps/cksum-cksum.Tpo -c -o src/cksum-cksum.o `test -f 'src/cksum.c' || echo './'`src/cksum.c
> src/cksum.c:190:30: error: invalid cpu feature string for builtin
> bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
> ^ ~~~~~~~~~~~~
> 1 error generated.
> make[2]: *** [src/cksum-cksum.o] Error 1
> make[2]: Leaving directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
> make[1]: *** [all-recursive] Error 1
That's a bit surprising.
I suspect the following will avoid the issue:
diff --git a/configure.ac b/configure.ac
index 5ea280f26..de380e16b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -693,8 +693,9 @@ AC_LINK_IFELSE(
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
a = _mm512_clmulepi64_epi128 (a, b, 0x00);
a = _mm512_shuffle_epi8 (a, b);
- return __builtin_cpu_supports ("avx512bw") &&
- __builtin_cpu_supports ("avx512f");
+ return __builtin_cpu_supports ("vpclmulqdq")
+ && __builtin_cpu_supports ("avx512bw")
+ && __builtin_cpu_supports ("avx512f");
}
]])
],[
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Sat, 24 May 2025 08:45:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78562 <at> debbugs.gnu.org (full text, mbox):
I had to patch the patch to become
--- configure.ac.orig 2025-02-26 16:53:31.000000000 +0100
+++ configure.ac 2025-05-24 10:08:06.000000000 +0200
@@ -696,8 +696,9 @@
__m256i a, b;
a = _mm256_clmulepi64_epi128 (a, b, 0x00);
a = _mm256_shuffle_epi8 (a, b);
- return __builtin_cpu_supports ("avx2") &&
- __builtin_cpu_supports ("vpclmulqdq");
+ return __builtin_cpu_supports ("vpclmulqdq")
+ && __builtin_cpu_supports ("avx512bw")
+ && __builtin_cpu_supports ("avx512f");
}
]])
],[
because the text after @@ and the line with so many zeros were too much (for my version of patch).
Now configure fails:
config.status: creating po/Makefile
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
alignof: found in coreutils-9.7/config.log
__GNUC_PREREQ: found in coreutils-9.7/config.log
unreachable: found in coreutils-9.7/config.log
MIN: found in coreutils-9.7/config.log
__fpending: found in coreutils-9.7/config.log
re_set_syntax: found in coreutils-9.7/config.log
re_compile_pattern: found in coreutils-9.7/config.log
re_search: found in coreutils-9.7/config.log
re_match: found in coreutils-9.7/config.log
free: found in coreutils-9.7/config.log
Warning: Configuration logfiles contain indications of -Wimplicit-int; check that features were not accidentally disabled:
found in coreutils-9.7/config.log
---> Building coreutils-devel
Executing: cd "/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7" && /usr/bin/make -j8 -w all
make: Entering directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/build-aux/missing' aclocal-1.16 -I m4
/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/build-aux/missing: line 81: aclocal-1.16: command not found
WARNING: 'aclocal-1.16' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<https://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<https://www.gnu.org/software/autoconf>
<https://www.gnu.org/software/m4/>
<https://www.perl.org/>
make: *** [aclocal.m4] Error 127
make: Leaving directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
Command failed: cd "/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7" && /usr/bin/make -j8 -w all
Exit code: 2
Error: Failed to build coreutils-devel: command execution failed
Reason is that already automake @1.17 is installed here…
I changed in configure line #5985:am__api_version='1.16' to become 1.17 and configure succeeded.
Is it possible to make the tools relying on that number to accept newer software? (I have no idea what these tools are good for, I am only suffering from them.)
--
Greetings
Pete
Don't force it; get a larger hammer.
– Anthony's Law of Force
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Sat, 24 May 2025 09:30:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 01:37 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> I suspect the following will avoid the issue:
It does not:
/usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx -mpclmul -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/libcksum_pclmul_a-cksum_pclmul.o -MD -MP -MF src/.deps/libcksum_pclmul_a-cksum_pclmul.Tpo -c -o src/libcksum_pclmul_a-cksum_pclmul.o `test -f 'src/cksum_pclmul.c' || echo './'`src/cksum_pclmul.c
src/cksum.c:190:30: error: invalid cpu feature string for builtin
bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
^ ~~~~~~~~~~~~
1 error generated.
make[2]: *** [src/cksum-cksum.o] Error 1
I then set GCC 14 as compiler to build (instead of Clang 17.0.6). The result is:
mv -f src/.deps/libcksum_avx2_a-cksum_avx2.Tpo src/.deps/libcksum_avx2_a-cksum_avx2.Po
depbase=`echo src/ls-dir.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
/opt/local/bin/gcc-mp-14 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -arch x86_64 -MT src/ls-dir.o -MD -MP -MF $depbase.Tpo -c -o src/ls-dir.o src/ls-dir.c &&\
mv -f $depbase.Tpo $depbase.Po
<stdin>:59:2: error: instruction requires: AVX-512 ISA
vmovdqa64 lC0(%rip), %zmm0
^
<stdin>:62:2: error: instruction requires: AVX-512 ISA
vmovdqa64 lC2(%rip), %zmm7
^
<stdin>:63:2: error: instruction requires: AVX-512 ISA
vmovdqa64 lC1(%rip), %zmm2
^
<stdin>:78:2: error: instruction requires: AVX-512 ISA
vmovdqa64 64(%rsp), %zmm3
^
<stdin>:82:2: error: instruction requires: AVX-512 ISA
vmovdqa64 128(%rsp), %zmm10
^
<stdin>:85:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:86:2: error: instruction requires: AVX-512 ISA
vmovdqa64 192(%rsp), %zmm9
^
<stdin>:87:2: error: instruction requires: AVX-512 ISA
vpxord %zmm3, %zmm1, %zmm1
^
<stdin>:88:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm10, %zmm10
^
<stdin>:89:2: error: instruction requires: AVX-512 ISA
vmovdqa64 256(%rsp), %zmm8
^
<stdin>:90:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm9, %zmm9
^
<stdin>:91:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm8, %zmm8
^
<stdin>:93:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm1, %zmm5
^
<stdin>:95:2: error: instruction requires: AVX-512 ISA
vmovdqa64 256(%rdi), %zmm6
^
<stdin>:97:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm1, %zmm1
^
<stdin>:99:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm10, %zmm4
^
<stdin>:100:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm6, %zmm6
^
<stdin>:101:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm10, %zmm10
^
<stdin>:102:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm9, %zmm3
^
<stdin>:103:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm9, %zmm9
^
<stdin>:104:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm8, %zmm11
^
<stdin>:105:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm1, %zmm5, %zmm6
^
<stdin>:106:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm8, %zmm8
^
<stdin>:107:2: error: instruction requires: AVX-512 ISA
vmovdqa64 64(%rdi), %zmm5
^
<stdin>:108:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm6, %zmm1
^
<stdin>:109:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm5, %zmm5
^
<stdin>:110:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm10, %zmm4, %zmm5
^
<stdin>:111:2: error: instruction requires: AVX-512 ISA
vmovdqa64 128(%rdi), %zmm4
^
<stdin>:112:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm5, %zmm10
^
<stdin>:113:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm4, %zmm4
^
<stdin>:114:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm9, %zmm3, %zmm4
^
<stdin>:115:2: error: instruction requires: AVX-512 ISA
vmovdqa64 192(%rdi), %zmm3
^
<stdin>:116:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm4, %zmm9
^
<stdin>:117:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:118:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm11, %zmm8, %zmm3
^
<stdin>:119:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, %zmm8
^
<stdin>:122:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm6, %zmm6
^
<stdin>:124:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm5, %zmm5
^
<stdin>:126:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm4, %zmm4
^
<stdin>:127:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:132:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm6, (%rax)
^
<stdin>:133:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm5, 64(%rax)
^
<stdin>:134:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm4, 128(%rax)
^
<stdin>:135:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, 192(%rax)
^
<stdin>:137:2: error: instruction requires: AVX-512 ISA
vmovdqa64 (%rax), %zmm3
^
<stdin>:143:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:144:2: error: instruction requires: AVX-512 ISA
vpxord %zmm3, %zmm1, %zmm1
^
<stdin>:146:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm7, %zmm1, %zmm4
^
<stdin>:147:2: error: instruction requires: AVX-512 ISA
vmovdqa64 64(%rax,%rsi), %zmm3
^
<stdin>:150:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm7, %zmm1, %zmm1
^
<stdin>:153:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:154:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm1, %zmm4, %zmm3
^
<stdin>:155:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, %zmm1
^
<stdin>:159:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:166:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, (%rax)
^
make[2]: *** [src/libcksum_avx512_a-cksum_avx512.o] Error 1
Is this more of an assembler problem? Installed are:
/usr/bin/as Apple LLVM version 10.0.0 (clang-1000.11.45.5)
/opt/local/bin/nasm NASM version 2.16.03 compiled on May 17 2024
/opt/local/bin/yasm yasm 1.3.0
no gas
To determine which assembler is used I added "-Wa,-v" to CFLAGS and got:
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
--
Greetings
Pete
The human brain operates at only 10% of its capacity. The rest is overhead for the operating system.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Sat, 24 May 2025 10:26:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 24/05/2025 10:29, Peter Dyballa wrote:
>
>> Am 24.05.2025 um 01:37 schrieb Pádraig Brady <P <at> draigBrady.com>:
>>
>> I suspect the following will avoid the issue:
>
> It does not:
>
> /usr/bin/clang -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx -mpclmul -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/libcksum_pclmul_a-cksum_pclmul.o -MD -MP -MF src/.deps/libcksum_pclmul_a-cksum_pclmul.Tpo -c -o src/libcksum_pclmul_a-cksum_pclmul.o `test -f 'src/cksum_pclmul.c' || echo './'`src/cksum_pclmul.c
> src/cksum.c:190:30: error: invalid cpu feature string for builtin
> bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
> ^ ~~~~~~~~~~~~
> 1 error generated.
> make[2]: *** [src/cksum-cksum.o] Error 1
>
>
> I then set GCC 14 as compiler to build (instead of Clang 17.0.6). The result is:
>
> mv -f src/.deps/libcksum_avx2_a-cksum_avx2.Tpo src/.deps/libcksum_avx2_a-cksum_avx2.Po
> depbase=`echo src/ls-dir.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> /opt/local/bin/gcc-mp-14 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -arch x86_64 -MT src/ls-dir.o -MD -MP -MF $depbase.Tpo -c -o src/ls-dir.o src/ls-dir.c &&\
> mv -f $depbase.Tpo $depbase.Po
> <stdin>:59:2: error: instruction requires: AVX-512 ISA
> vmovdqa64 lC0(%rip), %zmm0
> ^
It seems like you may have a mismatch between compiler (flags)
used at configure time and build time. These must match
so that code upsupported by your build is not enabled.
I'm surprised USE_AVX512_CRC32 is defined at all for you during your build?
thanks,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Sat, 24 May 2025 11:02:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 12:25 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> It seems like you may have a mismatch between compiler (flags)
> used at configure time and build time. These must match
> so that code upsupported by your build is not enabled.
This could happen, it even happens often with some open software: It checks whether the compiler understands a few dozens exotic options (maybe C++ related) and the uses this set when building the software.
Config.log contains (just an excerpt):
BUILD_CC='/opt/local/bin/gcc-mp-14'
BUILD_CFLAGS='-pipe -Os -Wa,-v -arch x86_64'
BUILD_CPPFLAGS='-I/opt/local/include'
BUILD_LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
CC='/opt/local/bin/gcc-mp-14'
CFLAGS='-pipe -Os -Wa,-v -arch x86_64'
CFLAG_VISIBILITY='-fvisibility=hidden'
and was using for the final test
configure:95467: /opt/local/bin/gcc-mp-14 -o conftest -pipe -Os -Wa,-v -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c -lintl >&5
An early test was:
configure:7178: /opt/local/bin/gcc-mp-14 -pipe -Os -Wa,-v -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c >&5
Configured was invoked as:
./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g --with-openssl=no --disable-year2038 CC=/opt/local/bin/gcc-mp-14 'CFLAGS=-pipe -Os -Wa,-v -arch x86_64' 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64' CPPFLAGS=-I/opt/local/include --no-create --no-recursion
Last GCC invocation before stepping on the bug was:
/opt/local/bin/gcc-mp-14 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -Wa,-v -arch x86_64 -MT src/date.o -MD -MP -MF $depbase.Tpo -c -o src/date.o src/date.c &&\
IMO BUILD_CFLAGS and CFLAGS are the same…
> I'm surprised USE_AVX512_CRC32 is defined at all for you during your build?
I have no idea…
"find . -type f -exec grep -in USE_AVX512_CRC32 {} /dev/null \;" produces this output:
./ChangeLog:496: * configure.ac (USE_AVX512_CRC32): Set to false if the function
./Makefile.in:714:@USE_AVX512_CRC32_TRUE <at> am__append_218 = src/libcksum_avx512.a
./Makefile.in:715:@USE_AVX512_CRC32_TRUE <at> am__append_219 = $(cksum_avx512_ldadd)
./Makefile.in:2051:@USE_AVX512_CRC32_TRUE <at> am_src_libcksum_avx512_a_OBJECTS = src/libcksum_avx512_a-cksum_avx512.$(OBJEXT)
./Makefile.in:7909:@USE_AVX512_CRC32_TRUE <at> src_libcksum_avx512_a_SOURCES = src/cksum_avx512.c src/cksum.h
./Makefile.in:7910:@USE_AVX512_CRC32_TRUE <at> cksum_avx512_ldadd = src/libcksum_avx512.a
./Makefile.in:7911:@USE_AVX512_CRC32_TRUE <at> src_libcksum_avx512_a_CFLAGS = -mavx512bw -mavx512f -mvpclmulqdq $(AM_CFLAGS)
./autom4te.cache/output.0:698:USE_AVX512_CRC32_FALSE
./autom4te.cache/output.0:699:USE_AVX512_CRC32_TRUE
./autom4te.cache/output.0:93182:printf "%s\n" "@%:@define USE_AVX512_CRC32 1" >>confdefs.h
./autom4te.cache/output.0:93186: USE_AVX512_CRC32_TRUE=
./autom4te.cache/output.0:93187: USE_AVX512_CRC32_FALSE='#'
./autom4te.cache/output.0:93189: USE_AVX512_CRC32_TRUE='#'
./autom4te.cache/output.0:93190: USE_AVX512_CRC32_FALSE=
./autom4te.cache/output.0:95897:if test -z "${USE_AVX512_CRC32_TRUE}" && test -z "${USE_AVX512_CRC32_FALSE}"; then
./autom4te.cache/output.0:95898: as_fn_error $? "conditional \"USE_AVX512_CRC32\" was never defined.
./autom4te.cache/output.1:698:USE_AVX512_CRC32_FALSE
./autom4te.cache/output.1:699:USE_AVX512_CRC32_TRUE
./autom4te.cache/output.1:93182:printf "%s\n" "@%:@define USE_AVX512_CRC32 1" >>confdefs.h
./autom4te.cache/output.1:93186: USE_AVX512_CRC32_TRUE=
./autom4te.cache/output.1:93187: USE_AVX512_CRC32_FALSE='#'
./autom4te.cache/output.1:93189: USE_AVX512_CRC32_TRUE='#'
./autom4te.cache/output.1:93190: USE_AVX512_CRC32_FALSE=
./autom4te.cache/output.1:95897:if test -z "${USE_AVX512_CRC32_TRUE}" && test -z "${USE_AVX512_CRC32_FALSE}"; then
./autom4te.cache/output.1:95898: as_fn_error $? "conditional \"USE_AVX512_CRC32\" was never defined.
./autom4te.cache/output.2:698:USE_AVX512_CRC32_FALSE
./autom4te.cache/output.2:699:USE_AVX512_CRC32_TRUE
./autom4te.cache/output.2:93182:printf "%s\n" "@%:@define USE_AVX512_CRC32 1" >>confdefs.h
./autom4te.cache/output.2:93186: USE_AVX512_CRC32_TRUE=
./autom4te.cache/output.2:93187: USE_AVX512_CRC32_FALSE='#'
./autom4te.cache/output.2:93189: USE_AVX512_CRC32_TRUE='#'
./autom4te.cache/output.2:93190: USE_AVX512_CRC32_FALSE=
./autom4te.cache/output.2:95897:if test -z "${USE_AVX512_CRC32_TRUE}" && test -z "${USE_AVX512_CRC32_FALSE}"; then
./autom4te.cache/output.2:95898: as_fn_error $? "conditional \"USE_AVX512_CRC32\" was never defined.
./autom4te.cache/traces.0:56231:m4trace:configure.ac:747: -1- m4_pattern_allow([^USE_AVX512_CRC32$])
./autom4te.cache/traces.0:56232:m4trace:configure.ac:750: -1- AM_CONDITIONAL([USE_AVX512_CRC32], [test $utils_cv_avx512_pclmul_intrinsic_exists = yes])
./autom4te.cache/traces.0:56233:m4trace:configure.ac:750: -1- m4_pattern_allow([^USE_AVX512_CRC32_TRUE$])
./autom4te.cache/traces.0:56234:m4trace:configure.ac:750: -1- m4_pattern_allow([^USE_AVX512_CRC32_FALSE$])
./autom4te.cache/traces.0:56235:m4trace:configure.ac:750: -1- _AM_SUBST_NOTMAKE([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.0:56236:m4trace:configure.ac:750: -1- _AM_SUBST_NOTMAKE([USE_AVX512_CRC32_FALSE])
./autom4te.cache/traces.1:17466:m4trace:configure.ac:747: -1- AC_DEFINE_TRACE_LITERAL([USE_AVX512_CRC32])
./autom4te.cache/traces.1:17467:m4trace:configure.ac:747: -1- m4_pattern_allow([^USE_AVX512_CRC32$])
./autom4te.cache/traces.1:17468:m4trace:configure.ac:747: -1- AH_OUTPUT([USE_AVX512_CRC32], [/* CRC32 calculation by avx512 hardware instructions enabled */
./autom4te.cache/traces.1:17469:@%:@undef USE_AVX512_CRC32])
./autom4te.cache/traces.1:17470:m4trace:configure.ac:750: -1- AM_CONDITIONAL([USE_AVX512_CRC32], [test $utils_cv_avx512_pclmul_intrinsic_exists = yes])
./autom4te.cache/traces.1:17471:m4trace:configure.ac:750: -1- AC_SUBST([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.1:17472:m4trace:configure.ac:750: -1- AC_SUBST_TRACE([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.1:17473:m4trace:configure.ac:750: -1- m4_pattern_allow([^USE_AVX512_CRC32_TRUE$])
./autom4te.cache/traces.1:17474:m4trace:configure.ac:750: -1- AC_SUBST([USE_AVX512_CRC32_FALSE])
./autom4te.cache/traces.1:17475:m4trace:configure.ac:750: -1- AC_SUBST_TRACE([USE_AVX512_CRC32_FALSE])
./autom4te.cache/traces.1:17476:m4trace:configure.ac:750: -1- m4_pattern_allow([^USE_AVX512_CRC32_FALSE$])
./autom4te.cache/traces.1:17477:m4trace:configure.ac:750: -1- _AM_SUBST_NOTMAKE([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.1:17478:m4trace:configure.ac:750: -1- _AM_SUBST_NOTMAKE([USE_AVX512_CRC32_FALSE])
./autom4te.cache/traces.2:17466:m4trace:configure.ac:747: -1- AC_DEFINE_TRACE_LITERAL([USE_AVX512_CRC32])
./autom4te.cache/traces.2:17467:m4trace:configure.ac:747: -1- m4_pattern_allow([^USE_AVX512_CRC32$])
./autom4te.cache/traces.2:17468:m4trace:configure.ac:747: -1- AH_OUTPUT([USE_AVX512_CRC32], [/* CRC32 calculation by avx512 hardware instructions enabled */
./autom4te.cache/traces.2:17469:@%:@undef USE_AVX512_CRC32])
./autom4te.cache/traces.2:17470:m4trace:configure.ac:750: -1- AM_CONDITIONAL([USE_AVX512_CRC32], [test $utils_cv_avx512_pclmul_intrinsic_exists = yes])
./autom4te.cache/traces.2:17471:m4trace:configure.ac:750: -1- AC_SUBST([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.2:17472:m4trace:configure.ac:750: -1- AC_SUBST_TRACE([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.2:17473:m4trace:configure.ac:750: -1- m4_pattern_allow([^USE_AVX512_CRC32_TRUE$])
./autom4te.cache/traces.2:17474:m4trace:configure.ac:750: -1- AC_SUBST([USE_AVX512_CRC32_FALSE])
./autom4te.cache/traces.2:17475:m4trace:configure.ac:750: -1- AC_SUBST_TRACE([USE_AVX512_CRC32_FALSE])
./autom4te.cache/traces.2:17476:m4trace:configure.ac:750: -1- m4_pattern_allow([^USE_AVX512_CRC32_FALSE$])
./autom4te.cache/traces.2:17477:m4trace:configure.ac:750: -1- _AM_SUBST_NOTMAKE([USE_AVX512_CRC32_TRUE])
./autom4te.cache/traces.2:17478:m4trace:configure.ac:750: -1- _AM_SUBST_NOTMAKE([USE_AVX512_CRC32_FALSE])
./config.log:154985:| #define USE_AVX512_CRC32 1
./config.log:158704:USE_AVX512_CRC32_FALSE='#'
./config.log:158705:USE_AVX512_CRC32_TRUE=''
./config.log:159742:#define USE_AVX512_CRC32 1
./config.status:713:S["USE_AVX512_CRC32_FALSE"]="#"
./config.status:714:S["USE_AVX512_CRC32_TRUE"]=""
./config.status:4329:D["USE_AVX512_CRC32"]=" 1"
./configure:698:USE_AVX512_CRC32_FALSE
./configure:699:USE_AVX512_CRC32_TRUE
./configure:93182:printf "%s\n" "#define USE_AVX512_CRC32 1" >>confdefs.h
./configure:93186: USE_AVX512_CRC32_TRUE=
./configure:93187: USE_AVX512_CRC32_FALSE='#'
./configure:93189: USE_AVX512_CRC32_TRUE='#'
./configure:93190: USE_AVX512_CRC32_FALSE=
./configure:95897:if test -z "${USE_AVX512_CRC32_TRUE}" && test -z "${USE_AVX512_CRC32_FALSE}"; then
./configure:95898: as_fn_error $? "conditional \"USE_AVX512_CRC32\" was never defined.
./configure.ac:747: AC_DEFINE([USE_AVX512_CRC32], [1],
./configure.ac:750:AM_CONDITIONAL([USE_AVX512_CRC32],
./configure~:682:USE_AVX512_CRC32_FALSE
./configure~:683:USE_AVX512_CRC32_TRUE
./configure~:93229:printf '%s\n' "#define USE_AVX512_CRC32 1" >>confdefs.h
./configure~:93233: USE_AVX512_CRC32_TRUE=
./configure~:93234: USE_AVX512_CRC32_FALSE='#'
./configure~:93236: USE_AVX512_CRC32_TRUE='#'
./configure~:93237: USE_AVX512_CRC32_FALSE=
./configure~:95932:if test -z "${USE_AVX512_CRC32_TRUE}" && test -z "${USE_AVX512_CRC32_FALSE}"; then
./configure~:95933: as_fn_error $? "conditional \"USE_AVX512_CRC32\" was never defined.
./lib/config.h:3936:#define USE_AVX512_CRC32 1
./lib/config.hin:3935:#undef USE_AVX512_CRC32
./src/cksum.c:189:# if USE_AVX512_CRC32
./src/local.mk:443:if USE_AVX512_CRC32
You might be also surprised seeing ./configure and ./configure~ (I am) – somehow configure is run twice. First invocation is
---> Configuring coreutils-devel
Executing: cd "/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7" && ./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g --with-openssl=no --disable-year2038
which comes to an end and then starts again here:
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating gnulib-tests/Makefile
config.status: creating lib/config.h
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
alignof: found in coreutils-9.7/config.log
__GNUC_PREREQ: found in coreutils-9.7/config.log
MIN: found in coreutils-9.7/config.log
__fpending: found in coreutils-9.7/config.log
re_set_syntax: found in coreutils-9.7/config.log
re_compile_pattern: found in coreutils-9.7/config.log
re_search: found in coreutils-9.7/config.log
re_match: found in coreutils-9.7/config.log
free: found in coreutils-9.7/config.log
---> Building coreutils-devel
Executing: cd "/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7" && /usr/bin/make -j8 -w all
make: Entering directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/build-aux/missing' aclocal-1.17 -I m4
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/build-aux/missing' autoconf
cd . && /bin/sh /opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/build-aux/missing automake-1.17 --gnu
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g --with-openssl=no --disable-year2038 CC=/opt/local/bin/gcc-mp-14 CFLAGS=-pipe -Os -Wa,-v -arch x86_64 LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 CPPFLAGS=-I/opt/local/include --no-create --no-recursion
Since I am also chasing bugs in my old PowerBook G4 I see there, Mac OS X 10.4.11, Tiger, just one single run of configure, same on my (almost) up-to-date MacBook with macOS Sonoma 14.7.4. Here, on macOS High Sierra, Version 10.13.6, configuration happens twice.
To me it looks as if automake-1.17 decides that a rebuild is necessary… (because version mismatch 1.16.x vs. 1.17?)
--
Greetings
Pete
Swimming in money is dry fun.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Wed, 28 May 2025 20:00:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-24 12:57, Peter Dyballa wrote:
> The output is: "O_DIRECTORY incorrectly succeeded!"
Thanks for checking. I installed fixes to Autoconf, Gnulib and Coreutils
to try to address the two bug reports <https://bugs.gnu.org/78562> and
<https://bugs.gnu.org/78562>.
The fixes are so complicated that patching is not likely to be easy, so
I generated a complete coreutils distribution tarball with the changes.
Please try this tarball. You can get it temporarily from:
https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
... or you can generate the tarball yourself from Savannah git master
coreutils.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Wed, 28 May 2025 20:17:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 28/05/2025 20:58, Paul Eggert wrote:
> On 2025-05-24 12:57, Peter Dyballa wrote:
>> The output is: "O_DIRECTORY incorrectly succeeded!"
>
> Thanks for checking. I installed fixes to Autoconf, Gnulib and Coreutils
> to try to address the two bug reports <https://bugs.gnu.org/78562> and
> <https://bugs.gnu.org/78562>.
>
> The fixes are so complicated that patching is not likely to be easy, so
> I generated a complete coreutils distribution tarball with the changes.
> Please try this tarball. You can get it temporarily from:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
>
> ... or you can generate the tarball yourself from Savannah git master
> coreutils.
Really nice work on this.
It's great this is all now encapsulated in gnulib,
and code can now assume contemporary systems in this regard.
thanks!
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Wed, 28 May 2025 20:20:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 28.05.2025 um 21:58 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> You can get it temporarily from:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
I fetched it! I'll try tomorrow on both Macs.
I'll also check with diffutils, https://debbugs.gnu.org/db/77/77840.html. Is it possible, and advised, to use the Gnulib sources from coreutils-9.7.39-c8d75 in diffutils 3.12? The new version of coreutils could cure many of its test failures, but diff itself has problems too – that might come from Gnulib…
Anyway, I hope I'll see more tomorrow!
--
Greetings
Pete
The human brain operates at only 10% of its capacity. The rest is overhead for the operating system.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 02:35:02 GMT)
Full text and
rfc822 format available.
Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):
On 2025-05-28 13:19, Peter Dyballa via GNU coreutils Bug Reports wrote:
> I'll also check with diffutils,https://debbugs.gnu.org/db/77/77840.html. Is it possible, and advised, to use the Gnulib sources from coreutils-9.7.39-c8d75 in diffutils 3.12?
I wouldn't advise it, as there are other changes (e.g., bleeding-edge
Autoconf). Let's get coreutils nailed down first.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 08:13:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 78562 <at> debbugs.gnu.org (full text, mbox):
First try with coreutils-9.7.39-c8d75 and Apple LLVM version 10.0.0 (clang-1000.11.45.5) AND without Pádraig's patch from a few days ago. I have to change 1.18 to 1.17 in aclocal.m4 and configure (for which I prepared patches to automate this). At the end of configure step I get:
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
alignof: found in coreutils-9.7.39-c8d75/config.log
__GNUC_PREREQ: found in coreutils-9.7.39-c8d75/config.log
unreachable: found in coreutils-9.7.39-c8d75/config.log
MIN: found in coreutils-9.7.39-c8d75/config.log
__fpending: found in coreutils-9.7.39-c8d75/config.log
re_set_syntax: found in coreutils-9.7.39-c8d75/config.log
re_compile_pattern: found in coreutils-9.7.39-c8d75/config.log
re_search: found in coreutils-9.7.39-c8d75/config.log
re_match: found in coreutils-9.7.39-c8d75/config.log
free: found in coreutils-9.7.39-c8d75/config.log
Warning: Configuration logfiles contain indications of -Wimplicit-int; check that features were not accidentally disabled:
found in coreutils-9.7.39-c8d75/config.log
When starting to build I get:
make: Entering directory `/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75'
cd . && /bin/sh /opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75/build-aux/missing automake-1.17 --gnu
aclocal.m4:17: warning: this file was generated for autoconf 2.72.84-63ffa.
You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
cd . && /bin/sh ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
It comes to a well-known error:
mv -f src/.deps/cksum-digest.Tpo src/.deps/cksum-digest.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -arch x86_64 -MT src/blake2/cksum-blake2b-ref.o -MD -MP -MF src/blake2/.deps/cksum-blake2b-ref.Tpo -c -o src/blake2/cksum-blake2b-ref.o `test -f 'src/blake2/blake2b-ref.c' || echo './'`src/blake2/blake2b-ref.c
mv -f src/blake2/.deps/cksum-blake2b-ref.Tpo src/blake2/.deps/cksum-blake2b-ref.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -arch x86_64 -MT src/blake2/cksum-b2sum.o -MD -MP -MF src/blake2/.deps/cksum-b2sum.Tpo -c -o src/blake2/cksum-b2sum.o `test -f 'src/blake2/b2sum.c' || echo './'`src/blake2/b2sum.c
mv -f src/blake2/.deps/cksum-b2sum.Tpo src/blake2/.deps/cksum-b2sum.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-sum.o -MD -MP -MF src/.deps/cksum-sum.Tpo -c -o src/cksum-sum.o `test -f 'src/sum.c' || echo './'`src/sum.c
mv -f src/.deps/cksum-sum.Tpo src/.deps/cksum-sum.Po
/usr/bin/clang -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -Wno-format-extra-args -Wno-tautological-constant-out-of-range-compare -pipe -Os -arch x86_64 -MT src/cksum-cksum.o -MD -MP -MF src/.deps/cksum-cksum.Tpo -c -o src/cksum-cksum.o `test -f 'src/cksum.c' || echo './'`src/cksum.c
src/cksum.c:189:30: error: invalid cpu feature string for builtin
bool avx512_enabled = (0 < __builtin_cpu_supports ("vpclmulqdq")
^ ~~~~~~~~~~~~
1 error generated.
make[2]: *** [src/cksum-cksum.o] Error 1
The build step was *not* a parallel one. cpuid tells me (excerpts):
CPU vendor string: 'GenuineIntel'
Signature: 0x000206a7
Family: 0x06 (6)
Model: 0x2a (42)
Stepping: 0x07 (7)
MMX instruction set (Intel, AMD)
FXSAVE/FXRSTOR instructions (Intel, AMD)
SSE instructions (Intel, AMD)
SSE2 instructions (Intel, AMD)
Base features, ecx:
SSE3 instructions (Intel, AMD)
...
SSSE3 instructions (Intel, AMD)
...
SSE4.1 instructions (Intel, AMD)
SSE4.2 instructions (Intel, AMD)
...
AVX instructions (Intel, AMD)
Extended State Enumeration
Valid bit fields for lower 32 bits of XCR0:
0 - Legacy x87
1 - 128-bit SSE
2 - 256-bit AVX YMM_Hi128
Extended state for 256-bit AVX YMM_Hi128 requires 256 bytes, offset 576
Processor Name: Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz
The latter corresponds with documentation: Intel Core i7 (2760QM, 2860QM) ("Sandy Bridge").
Configuring to use GCC 14.2 brings a warning:
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
alignof: found in coreutils-9.7.39-c8d75/config.log
__GNUC_PREREQ: found in coreutils-9.7.39-c8d75/config.log
MIN: found in coreutils-9.7.39-c8d75/config.log
__fpending: found in coreutils-9.7.39-c8d75/config.log
re_set_syntax: found in coreutils-9.7.39-c8d75/config.log
re_compile_pattern: found in coreutils-9.7.39-c8d75/config.log
re_search: found in coreutils-9.7.39-c8d75/config.log
re_match: found in coreutils-9.7.39-c8d75/config.log
free: found in coreutils-9.7.39-c8d75/config.log
The build step starts with
aclocal.m4:17: warning: this file was generated for autoconf 2.72.84-63ffa.
You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
cd . && /bin/sh ./config.status Makefile depfiles
Now the error is more explicit:
mv -f src/.deps/cksum-cksum.Tpo src/.deps/cksum-cksum.Po
/opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I./lib -DHASH_ALGO_CKSUM=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -arch x86_64 -MT src/cksum-crctab.o -MD -MP -MF src/.deps/cksum-crctab.Tpo -c -o src/cksum-crctab.o `test -f 'src/crctab.c' || echo './'`src/crctab.c
mv -f src/.deps/cksum-crctab.Tpo src/.deps/cksum-crctab.Po
/opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx512bw -mavx512f -mvpclmulqdq -pipe -Os -arch x86_64 -MT src/libcksum_avx512_a-cksum_avx512.o -MD -MP -MF src/.deps/libcksum_avx512_a-cksum_avx512.Tpo -c -o src/libcksum_avx512_a-cksum_avx512.o `test -f 'src/cksum_avx512.c' || echo './'`src/cksum_avx512.c
<stdin>:59:2: error: instruction requires: AVX-512 ISA
vmovdqa64 lC0(%rip), %zmm0
^
<stdin>:62:2: error: instruction requires: AVX-512 ISA
vmovdqa64 lC2(%rip), %zmm7
^
<stdin>:63:2: error: instruction requires: AVX-512 ISA
vmovdqa64 lC1(%rip), %zmm2
^
<stdin>:78:2: error: instruction requires: AVX-512 ISA
vmovdqa64 64(%rsp), %zmm3
^
<stdin>:82:2: error: instruction requires: AVX-512 ISA
vmovdqa64 128(%rsp), %zmm10
^
<stdin>:85:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:86:2: error: instruction requires: AVX-512 ISA
vmovdqa64 192(%rsp), %zmm9
^
<stdin>:87:2: error: instruction requires: AVX-512 ISA
vpxord %zmm3, %zmm1, %zmm1
^
<stdin>:88:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm10, %zmm10
^
<stdin>:89:2: error: instruction requires: AVX-512 ISA
vmovdqa64 256(%rsp), %zmm8
^
<stdin>:90:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm9, %zmm9
^
<stdin>:91:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm8, %zmm8
^
<stdin>:93:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm1, %zmm5
^
<stdin>:95:2: error: instruction requires: AVX-512 ISA
vmovdqa64 256(%rdi), %zmm6
^
<stdin>:97:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm1, %zmm1
^
<stdin>:99:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm10, %zmm4
^
<stdin>:100:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm6, %zmm6
^
<stdin>:101:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm10, %zmm10
^
<stdin>:102:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm9, %zmm3
^
<stdin>:103:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm9, %zmm9
^
<stdin>:104:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm2, %zmm8, %zmm11
^
<stdin>:105:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm1, %zmm5, %zmm6
^
<stdin>:106:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm2, %zmm8, %zmm8
^
<stdin>:107:2: error: instruction requires: AVX-512 ISA
vmovdqa64 64(%rdi), %zmm5
^
<stdin>:108:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm6, %zmm1
^
<stdin>:109:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm5, %zmm5
^
<stdin>:110:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm10, %zmm4, %zmm5
^
<stdin>:111:2: error: instruction requires: AVX-512 ISA
vmovdqa64 128(%rdi), %zmm4
^
<stdin>:112:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm5, %zmm10
^
<stdin>:113:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm4, %zmm4
^
<stdin>:114:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm9, %zmm3, %zmm4
^
<stdin>:115:2: error: instruction requires: AVX-512 ISA
vmovdqa64 192(%rdi), %zmm3
^
<stdin>:116:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm4, %zmm9
^
<stdin>:117:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:118:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm11, %zmm8, %zmm3
^
<stdin>:119:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, %zmm8
^
<stdin>:122:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm6, %zmm6
^
<stdin>:124:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm5, %zmm5
^
<stdin>:126:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm4, %zmm4
^
<stdin>:127:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:132:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm6, (%rax)
^
<stdin>:133:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm5, 64(%rax)
^
<stdin>:134:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm4, 128(%rax)
^
<stdin>:135:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, 192(%rax)
^
<stdin>:137:2: error: instruction requires: AVX-512 ISA
vmovdqa64 (%rax), %zmm3
^
<stdin>:143:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:144:2: error: instruction requires: AVX-512 ISA
vpxord %zmm3, %zmm1, %zmm1
^
<stdin>:146:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $0, %zmm7, %zmm1, %zmm4
^
<stdin>:147:2: error: instruction requires: AVX-512 ISA
vmovdqa64 64(%rax,%rsi), %zmm3
^
<stdin>:150:2: error: instruction requires: AVX-512 ISA
vpclmulqdq $17, %zmm7, %zmm1, %zmm1
^
<stdin>:153:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:154:2: error: instruction requires: AVX-512 ISA
vpternlogd $150, %zmm1, %zmm4, %zmm3
^
<stdin>:155:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, %zmm1
^
<stdin>:159:2: error: instruction requires: AVX-512 BW ISA
vpshufb %zmm0, %zmm3, %zmm3
^
<stdin>:166:2: error: instruction requires: AVX-512 ISA
vmovdqa64 %zmm3, (%rax)
^
make[2]: *** [src/libcksum_avx512_a-cksum_avx512.o] Error 1
I do not know how to handle the warnings at the end of configure step. The warning when build starts should be resolved by performing what it tells, which can easily be performed in GNU Emacs.
In MacPorts I am able to perform single steps: extract, patch, configure, then build, test, install. After the configure step, which inherently performs extract and patch, I invoked in GNU Emacs "/bin/sh ./config.status Makefile depfiles" in the dired buffer that displayed coreutils-9.7.39-c8d75. But the build warning about the aclocal.m4 mismatch was shown again when building started.
--
Greetings
Pete
A blizzard is when it snows sideways.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 09:07:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 29/05/2025 09:12, Peter Dyballa wrote:
> /opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -mavx512bw -mavx512f -mvpclmulqdq -pipe -Os -arch x86_64 -MT src/libcksum_avx512_a-cksum_avx512.o -MD -MP -MF src/.deps/libcksum_avx512_a-cksum_avx512.Tpo -c -o src/libcksum_avx512_a-cksum_avx512.o `test -f 'src/cksum_avx512.c' || echo './'`src/cksum_avx512.c
> <stdin>:59:2: error: instruction requires: AVX-512 ISA
> vmovdqa64 lC0(%rip), %zmm0
> ^
The above suggests that `/opt/local/bin/gcc-mp-14 -std=gnu23 ... -mavx512bw -mavx512f -mvpclmulqdq ... -arch x86_64`
isn't enough to support building with AVX-512 ISA.
That should be fine though if the same determination is made at configure time,
which would cause USE_AVX512_CRC32 to _not_ be defined.
You should be able to see the configure time checks with:
grep -A3 'avx512 pclmul intrinsic exists' config.log
cheers,
Pádraig
p.s. I'm surprised you need autoconf when building from Paul's snapshot,
are you further patching ac files during the macports build or something?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 09:56:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 11:06 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
>> <stdin>:59:2: error: instruction requires: AVX-512 ISA
>> vmovdqa64 lC0(%rip), %zmm0
>> ^
>
> The above suggests that `/opt/local/bin/gcc-mp-14 -std=gnu23 ... -mavx512bw -mavx512f -mvpclmulqdq ... -arch x86_64`
> isn't enough to support building with AVX-512 ISA.
>
> That should be fine though if the same determination is made at configure time,
> which would cause USE_AVX512_CRC32 to _not_ be defined.
> You should be able to see the configure time checks with:
>
> grep -A3 'avx512 pclmul intrinsic exists' config.log
Output is:
configure:94181: checking if avx512 pclmul intrinsic exists
configure:94209: /opt/local/bin/gcc-mp-14 -std=gnu23 -o conftest -mavx512bw -mavx512f -mvpclmulqdq -pipe -Os -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c >&5
configure:94209: $? = 0
configure:94225: result: yes
configure's invocation is:
./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g --with-openssl=no --disable-year2038
>
> cheers,
> Pádraig
>
> p.s. I'm surprised you need autoconf when building from Paul's snapshot,
> are you further patching ac files during the macports build or something?
Nothing more, just the two files mentioned:
--- aclocal.m4~ 2025-05-28 21:37:07.000000000 +0200
+++ aclocal.m4 2025-05-29 09:11:06.000000000 +0200
@@ -32,10 +32,10 @@
# generated from the m4 files accompanying Automake X.Y.
# (This private macro should not be called outside this file.)
AC_DEFUN([AM_AUTOMAKE_VERSION],
-[am__api_version='1.18'
+[am__api_version='1.17'
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.
-m4_if([$1], [1.18], [],
+m4_if([$1], [1.17], [],
[AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
])
@@ -51,7 +51,7 @@
# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
# This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-[AM_AUTOMAKE_VERSION([1.18])dnl
+[AM_AUTOMAKE_VERSION([1.17])dnl
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
_AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
--- configure~ 2025-05-28 21:49:56.000000000 +0200
+++ configure 2025-05-29 09:11:55.000000000 +0200
@@ -6008,7 +6008,7 @@
ac_config_headers="$ac_config_headers lib/config.h:lib/config.hin"
-am__api_version='1.18'
+am__api_version='1.17'
But that's over, I managed to install automake 1.18. (I'll try the same on my old PowerBook G4 as well to test the new version of coreutils! Only that the configure step seems to take hours now… And the warnings continue to exist.)
--
Greetings
~ O
Pete ~~_\\_/%
~ O o
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 10:18:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 78562 <at> debbugs.gnu.org (full text, mbox):
Trying to install automake 1.18 I get a complaint when preparing for the job (with automake-1.18.tar.xz.sig and automake-1.18.tar.xz @ GnuPG 2.4.7):
gpg: Signature made Tue May 27 22:47:11 2025 CEST
gpg: using RSA key 17D3311B14BC0F248267BF020716748A30D155AD
gpg: key 0716748A30D155AD: no user ID
gpg: Total number processed: 1
gpg: Can't check signature: No public key
Exit 2
Build and install of automake 1.18 succeed (test has problems, including endless halt), but coreutils-9.7.39-c8d75 still do not build, the error is exactly the same.
--
Greetings
Pete
Sorry my terrible English, my native language Lisp
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 11:06:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 28.05.2025 um 21:58 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
Solves the problem: ./mv -v k out succeeds: k vanishes and out is still a file! (Now testing.)
--
Greetings
Pete
No matter which way you ride, it's uphill and against the wind.
– First Law of Bicycling
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 11:09:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 29/05/2025 10:54, Peter Dyballa wrote:
>
>> Am 29.05.2025 um 11:06 schrieb Pádraig Brady <P <at> draigBrady.com>:
>>
>>> <stdin>:59:2: error: instruction requires: AVX-512 ISA
>>> vmovdqa64 lC0(%rip), %zmm0
>>> ^
>>
>> The above suggests that `/opt/local/bin/gcc-mp-14 -std=gnu23 ... -mavx512bw -mavx512f -mvpclmulqdq ... -arch x86_64`
>> isn't enough to support building with AVX-512 ISA.
>>
>> That should be fine though if the same determination is made at configure time,
>> which would cause USE_AVX512_CRC32 to _not_ be defined.
>> You should be able to see the configure time checks with:
>>
>> grep -A3 'avx512 pclmul intrinsic exists' config.log
>
> Output is:
>
> configure:94181: checking if avx512 pclmul intrinsic exists
> configure:94209: /opt/local/bin/gcc-mp-14 -std=gnu23 -o conftest -mavx512bw -mavx512f -mvpclmulqdq -pipe -Os -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c >&5
> configure:94209: $? = 0
> configure:94225: result: yes
OK that does suggest the configure test isn't sufficient here
(Nor the patch to that I sent previously).
Since this is for an optional performance enhancement,
you should be able to bypass this build issue with:
./configure utils_cv_avx512_pclmul_intrinsic_exists=no ...
You might have to also disable other intrinsics, as listed by:
grep CACHE.*utils_cv.*intrins configure.ac
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 11:21:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 13:08 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> OK that does suggest the configure test isn't sufficient here
> (Nor the patch to that I sent previously).
I built *without* it, assuming the updated sources would contain it. Should I try again *with* your patch applied?
> You might have to also disable other intrinsics, as listed by:
>
> grep CACHE.*utils_cv.*intrins configure.ac
From last failed build:
AC_CACHE_VAL([utils_cv_vmull_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_pclmul_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_avx2_pclmul_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_avx512_pclmul_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_avx2_intrinsic_exists],[
I'm going to perform a "./configure utils_cv_avx512_pclmul_intrinsic_exists=no ..."…
--
Greetings
Pete
"A TRUE Klingon warrior does not comment his code."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 11:29:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 29/05/2025 12:20, Peter Dyballa wrote:
>
>
>> Am 29.05.2025 um 13:08 schrieb Pádraig Brady <P <at> draigBrady.com>:
>>
>> OK that does suggest the configure test isn't sufficient here
>> (Nor the patch to that I sent previously).
>
> I built *without* it, assuming the updated sources would contain it. Should I try again *with* your patch applied?
Well I didn't apply it, since you said it didn't help.
It would be worth double checking if you can,
but the gcc error does suggest to me it would not help.
cheers,
Padraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 11:40:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 13:08 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> Since this is for an optional performance enhancement,
> you should be able to bypass this build issue with:
>
> ./configure utils_cv_avx512_pclmul_intrinsic_exists=no ...
Performed:
Executing: cd "/opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75" && ./configure --prefix=/opt/local --disable-silent-rules --program-prefix=g --with-openssl=no --disable-year2038 utils_cv_avx512_pclmul_intrinsic_exists=no
>
> You might have to also disable other intrinsics, as listed by:
>
> grep CACHE.*utils_cv.*intrins configure.ac
Produces the same as before:
AC_CACHE_VAL([utils_cv_vmull_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_pclmul_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_avx2_pclmul_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_avx512_pclmul_intrinsic_exists],[
AC_CACHE_VAL([utils_cv_avx2_intrinsic_exists],[
Build results in: SUCCESS.
--
Greetings
Pete
It is so hot in some places that the people there have to live in other places.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 12:19:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 13:28 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> It would be worth double checking if you can,
Applying it does not change the output of "grep 'CACHE.*utils_cv.*intrins' configure.ac" when configure'd with "utils_cv_avx512_pclmul_intrinsic_exists=no".
Result is the usual error.
--
Greetings
Pete
Government is actually the worst failure of civilized man. There has never been a really good one, and even those that are most tolerable are arbitrary, cruel, grasping and unintelligent.
– H. L. Mencken
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 12:35:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 13:28 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> It would be worth double checking if you can,
Applying your patch AND configuring with "utils_cv_avx512_pclmul_intrinsic_exists=no" brings successful build. So your patch does not hurt…
--
Greetings
Pete
~ o
~_\\_/\
~ O O
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 14:48:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-29 03:16, Peter Dyballa wrote:
> gpg: Can't check signature: No public key
You can fix that by importing the public key of whoever signed the
compressed tarball. See <https://savannah.gnu.org/users/karl>.
E.g.:
wget -O karl.key 'https://savannah.gnu.org/people/viewgpg.php?user_id=685'
gpg --import karl.key
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 15:12:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 16:47 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> On 2025-05-29 03:16, Peter Dyballa wrote:
>> gpg: Can't check signature: No public key
>
> You can fix that by importing the public key of whoever signed the compressed tarball. See <https://savannah.gnu.org/users/karl>.
>
> E.g.:
>
> wget -O karl.key 'https://savannah.gnu.org/people/viewgpg.php?user_id=685'
> gpg --import karl.key
I already fetched a few keys or certificates that way – but where is the indication that Karl Berry's public key is needed? Only afterwards I get:
gpg: Good signature from "Karl Berry <karl <at> freefriends.org>" [unknown]
--
Greetings
Pete
I consider religion godesque.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 15:58:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 28.05.2025 um 21:58 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
This is the result of testing:
========================================================
GNU coreutils 9.7.39-c8d75: ./tests/test-suite.log
========================================================
# TOTAL: 659
# PASS: 461
# SKIP: 194
# XFAIL: 0
# FAIL: 4
# XPASS: 0
# ERROR: 0
System information (uname -a): Darwin 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh
FAILures come from missing tests/env/env-S, tests/sort/sort-discrim, tests/timeout/timeout-group, and tests/cp/attr-existing. The latter could be SKIPped because Tiger can only handle some attribute basics:
+ returns_ 1 cp -a --attributes-only sym1 file2
cp: cannot create symbolic link 'file2': File exists
+ cmp file2 file2.exp
+ cp -a --remove-destination --attributes-only sym1 file2
cp: preserving times for 'file2': Function not implemented
I also performed some commands with mv and cp manually that failed before. Now they do work.
Testing diffutils 3.12 does not work here – because the function SIGSEGV_FOR_ALL_SIGNALS() does not exist, so no build. But I think the coreutils are now OK!
--
Greetings
Pete
If men could get pregnant, abortion would be a sacrament.
– Florynce Kennedy
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 16:04:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-29 08:11, Peter Dyballa wrote:
> where is the indication that Karl Berry's public key is needed?
I suppose you're supposed to infer it from the release announcement by karl.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 16:11:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-23 16:37, Pádraig Brady wrote:
> I suspect the following will avoid the issue:
Given the followup emails, and the fact that vpclmulqdq is a
not-always-implemented extension to AVX-512, it seems like the patch
can't hurt and might help so I installed it.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Thu, 29 May 2025 16:13:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Peter Dyballa <Peter_Dyballa <at> Web.DE>:
bug acknowledged by developer.
(Thu, 29 May 2025 16:13:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 78562-done <at> debbugs.gnu.org (full text, mbox):
On 2025-05-29 08:57, Peter Dyballa wrote:
> I think the coreutils are now OK!
Thanks for checking; closing the two coreutils bug reports.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 16:49:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-29 01:12, Peter Dyballa wrote:
> First try with coreutils-9.7.39-c8d75 and Apple LLVM version 10.0.0 (clang-1000.11.45.5) AND without Pádraig's patch from a few days ago. I have to change 1.18 to 1.17 in aclocal.m4 and configure (for which I prepared patches to automate this).
For future tests of diffutils etc. let's not do that. Let's use the
latest version of everything. You shouldn't need to run even automake
1.18; you should be able to build from a tarball without running
aclocal, autoconf, automake, etc. If that's not working for some reason
let's fix that first.
> Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
This warning is generated by MacPorts; see
<https://trac.macports.org/wiki/WimplicitFunctionDeclaration>. You'll
need a Mac expert to decide whether the warnings are bogus. My guess is
that they are, but I'm no expert.
Must you use MacPorts? (Remember, I'm no Mac expert.) Can't you just use
'./configure; make' like INSTALL says?
> cd . && /bin/sh /opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75/build-aux/missing automake-1.17 --gnu
This suggests that you updated configure.ac or m4/*.m4 or */Makefile.am
or something like that. Let's not do that. Just unpack the tarball and
use it without changing any files or their timestamps. If you need to
make patches, you'll need to later run "./bootstrap" with Automake 1.18
and bleeding-edge-from-Savannah Autoconf and I wouldn't trust doing that
on an ancient Mac OS platform.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 29 May 2025 17:27:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 29.05.2025 um 18:48 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> Must you use MacPorts? (Remember, I'm no Mac expert.) Can't you just use './configure; make' like INSTALL says?
MacPorts' Portfile is such a fine "remote control" – you can record patches, configure arguments, compiler flags etc. and also comment why you did this or that. GNU Emacs only keeps a history of compile commands – according to my knowledge.
And another advantage of using MacPorts is that you can easily remove from disk what you installed some time before (and reset the system to some standards). And when you're using old tools like rsync all your changes to Portfiles go away – including self-written patch files (which *is* bad). Using modern git instead seems to keep many changes and additions. But you can also feed your own local private repository! And it can be switched on or off in a MacPorts configuration text file.
There are cases when MacPorts cannot be used at all: when tests are using sockets to communicate with a DB or whatever. Because the path name of the socket inside the build (or disaster) area is longer than 104 or 105 characters it cannot be created!
>> cd . && /bin/sh /opt/local/var/macports/build/_opt_mports_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7.39-c8d75/build-aux/missing automake-1.17 --gnu
>
> This suggests that you updated configure.ac or m4/*.m4 or */Makefile.am or something like that. Let's not do that. Just unpack the tarball and use it without changing any files or their timestamps. If you need to make patches, you'll need to later run "./bootstrap" with Automake 1.18 and bleeding-edge-from-Savannah Autoconf and I wouldn't trust doing that on an ancient Mac OS platform.
Configure stopped configuring when it could not find "aclocal-1.16" or "aclocal-1.18", exactly these executables, because of reasons I do not know why at all. I do not know much about the use of these tools, was never a software developer. So my first idea was to rename the text strings (I could have also provided sym-links by those names…).
Mac OS X 10.4.11, Tiger, has an inherent problem with time stamps: they must be at least 2 sec apart! I noticed it once and later I saw some configure scripts (PostgreSQL?) check for the length of the time interval. Could this disturb a simple ./configure && make?
--
Greetings
Pete
"Indentation?! I will show you how to indent when I indent your skull!"
– Unknown Klingon typist.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Fri, 30 May 2025 06:25:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-29 10:25, Peter Dyballa wrote:
> MacPorts' Portfile is such a fine "remote control"
As long as it doesn't try to run autoconf etc. I won't mind.
> Configure stopped configuring when it could not find "aclocal-1.16" or "aclocal-1.18", exactly these executables, because of reasons I do not know why at all. I do not know much about the use of these tools, was never a software developer. So my first idea was to rename the text strings (I could have also provided sym-links by those names…).
None of that will work in general, unfortunately. We have to arrange for
these programs to not be used (or else port them all to your platform,
which sounds dicey).
> Mac OS X 10.4.11, Tiger, has an inherent problem with time stamps: they must be at least 2 sec apart!
That's weird, as many sources say that Mac OS X's HFS+ file system
timestamp resolution is 1 s; see, for example
<https://arstechnica.com/gadgets/2011/07/mac-os-x-10-7/#page-12>.
Possibly you are running on a FAT32 file system, or something like that?
If so, you might try switching to a better file system.
But even then I don't see why this would cause 'make' to think file
timestamps are out of date.
If you have time to debug this, you could try starting with a vanilla
tarball, run './configure', and then see which files appear to be out of
date but aren't.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Fri, 30 May 2025 09:40:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 30.05.2025 um 08:24 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
>> Mac OS X 10.4.11, Tiger, has an inherent problem with timestamps: they must be at least 2 sec apart!
>
> That's weird, as many sources say that Mac OS X's HFS+ file system timestamp resolution is 1 s; see, for example <https://arstechnica.com/gadgets/2011/07/mac-os-x-10-7/#page-12>. Possibly you are running on a FAT32 file system, or something like that? If so, you might try switching to a better file system.
No, I am using case-sensible HFS+, a variant of the default case-preserving HFS+ (in that case a file created as "a" stays so, and a file created as "A" stays in that spelling, but "a" and "A" cannot exist at the same time in the same directory, which gives trouble when a tool would like to create a file with a different spelling of the same name while my variant can support both "A" and "a"). GNU ls allows to display files' timestamps in detail, down to µsec or less, but on Tiger it's only a long series of zeroes.
I just tried to manually repeat something similar to what a programme once did, creating many files and then closing them at once: "gtouch a ; gtouch b ; … ; gtouch y ; gtouch z" and then "gls -l --time-style=full-iso a b c … x y z" – and the latter shows, as excerpt:
-rw-r--r-- 1 pete wheel 0 2025-05-30 09:50:04.000000000 +0200 d
-rw-r--r-- 1 pete wheel 0 2025-05-30 09:50:04.000000000 +0200 e
-rw-r--r-- 1 pete wheel 0 2025-05-30 09:50:05.000000000 +0200 f
-rw-r--r-- 1 pete wheel 0 2025-05-30 09:50:05.000000000 +0200 g
It's one second resolution, according to what original ls can provide as information. And according to what John Siracusa writes in the article you cite.
I found something in configure's output:
checking filesystem timestamp resolution... 2
And coreutils-9.7.39-c8d75 find this too! Looking into the code it's stated that a 1 sec resolution is expressed as 2 sec for practical reasons. And I think for practical reasons too I decided to update my old impressions, since 2 sec came from tools to exactly determine the amount of time. So, OK, new update: one second. And I found this on my latest multi-core intel based MacBook too… (with complicated APFS, https://en.wikipedia.org/wiki/Apple_File_System)
>
> But even then I don't see why this would cause 'make' to think file timestamps are out of date.
My assumption was that when tar has to extrapolate an exact timestamp to something inexact it needs rounding, which can make more than one file have the same timestamp. Which one was first, which last? Make and such rely on timestamps and could get fooled by equal timestamps.
>
> If you have time to debug this, you could try starting with a vanilla tarball, run './configure', and then see which files appear to be out of date but aren't.
When extracting your tarball I get with gls -lt --time-style=full-iso (excerpt):
-rw-r--r-- 1 macports wheel 485884 2025-05-28 21:51:42.000000000 +0200 ChangeLog
-rw-r--r-- 1 macports wheel 2546716 2025-05-28 21:51:42.000000000 +0200 Makefile.in
drwxr-xr-x 12 macports wheel 384 2025-05-28 21:51:42.000000000 +0200 doc
drwxr-xr-x 748 macports wheel 23936 2025-05-28 21:51:41.000000000 +0200 gnulib-tests
drwxr-xr-x 105 macports wheel 3360 2025-05-28 21:51:39.000000000 +0200 po
drwxr-xr-x 74 macports wheel 2368 2025-05-28 21:51:34.000000000 +0200 tests
drwxr-xr-x 25 macports wheel 800 2025-05-28 21:51:32.000000000 +0200 build-aux
drwxr-xr-x 856 macports wheel 27392 2025-05-28 21:51:32.000000000 +0200 lib
drwxr-xr-x 221 macports wheel 7072 2025-05-28 21:51:32.000000000 +0200 man
drwxr-xr-x 174 macports wheel 5568 2025-05-28 21:51:32.000000000 +0200 src
drwxr-xr-x 6 macports wheel 192 2025-05-28 21:51:29.000000000 +0200 gl
drwxr-xr-x 471 macports wheel 15072 2025-05-28 21:51:29.000000000 +0200 m4
-rw-r--r-- 1 macports wheel 54530 2025-05-28 21:50:46.000000000 +0200 THANKS
-rw-r--r-- 1 macports wheel 2110 2025-05-28 21:50:46.000000000 +0200 THANKS-to-translators
-rw-r--r-- 1 macports wheel 4774 2025-05-28 21:50:45.000000000 +0200 GNUmakefile
-rwxr-xr-x 1 macports wheel 2423338 2025-05-28 21:49:56.000000000 +0200 configure
-rw-r--r-- 1 macports wheel 63917 2025-05-28 21:37:07.000000000 +0200 aclocal.m4
-rw-r--r-- 1 macports wheel 29615 2025-05-28 21:16:19.000000000 +0200 configure.ac
-rw-r--r-- 1 macports wheel 38340 2025-05-27 04:27:10.000000000 +0200 cfg.mk
-rw-r--r-- 1 macports wheel 255580 2025-05-24 07:52:31.000000000 +0200 NEWS
-rw-r--r-- 1 macports wheel 7963 2025-05-12 02:59:47.000000000 +0200 Makefile.am
-rw-r--r-- 1 macports wheel 6649 2025-05-12 02:59:47.000000000 +0200 README
-rw-r--r-- 1 macports wheel 6640 2025-05-12 02:59:47.000000000 +0200 TODO
-rw-r--r-- 1 macports wheel 7887 2025-05-12 02:59:47.000000000 +0200 bootstrap.conf
-rw-r--r-- 1 macports wheel 22777 2025-05-12 02:59:47.000000000 +0200 init.cfg
-rwxr-xr-x 1 macports wheel 57267 2025-05-11 19:16:23.000000000 +0200 bootstrap
What MacPorts does is quite what you suggest: creating a directory "work" into which to extract the archive, apply patches to files (or create them) if necessary, then run configure or invoke CMake or use a Python, Perl, Ruby, Go, … whatever tool. Only when explicitly written in Portfile or some particle in the software to build demands it, then autoconf gets used (for example when building GNU Emacs from sources fetched with git: system -W ${worksrcpath} "sh ./autogen.sh").
I think coreutils are now prepared to work correctly on operating systems from the last quarter century, this millennium. I would rather like to test them on Mac OS X 10.5.8, Leopard, after upgrading the MacPorts installed software. And then "debug" diffutils – or give them up…
Anyway, I am retired from UNIX system administration and can provide tests on some Mac OS X and macOS systems.
--
Greetings
Pete
No one is patriotic about taxes.
– George Orwell, Orwell Diaries 1938-1942, (1940-08-09)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Fri, 30 May 2025 16:47:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 78562 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-30 02:38, Peter Dyballa wrote:
> My assumption was that when tar has to extrapolate an exact timestamp to something inexact it needs rounding, which can make more than one file have the same timestamp.
As far as I know, all 'tar' implementations floor (i.e., truncate
towards minus infinity) rather than round. And I think POSIX requires
this for 'pax', which is POSIX's replacement for 'tar'. But even if
macOS 'tar' rounds, we should be OK so long as its timestamp conversion
function (whether floor or round or something else) is monotonically
nondecreasing.
> Make and such rely on timestamps and could get fooled by equal timestamps.
Only if 'make' considers equal timestamps to be out of date. Although
POSIX allows this behavior, as far as I know only HP-UX 'make' does it.
What happens on your platform when you run the following shell commands
in a fresh directory?
touch -t 202505290000 a b
gls -l --time-style=full a b
echo 'b: a; echo ouch; false' >Makefile
make
If this outputs 'ouch' then your 'make' acts like HP-UX 'make', which
would surprise me.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Fri, 30 May 2025 18:46:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 30.05.2025 um 18:46 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> What happens on your platform when you run the following shell commands in a fresh directory?
>
> touch -t 202505290000 a b
> gls -l --time-style=full a b
> echo 'b: a; echo ouch; false' >Makefile
> make
On PPC Leopard, Mac OS X 10.5.8:
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 a
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 b
gmake: 'b' is up to date.
On x86_64 High Sierra, macOS 10.13.6:
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 a
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 b
gmake: 'b' is up to date.
On x86_64 Sonoma, macOS 14.7.4:
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 a
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 b
gmake: 'b' is up to date.
Here the system's GNU Make 3.81 needed a minute or such to tell that nothing needs to be done. (gmake is GNU Make 4.4.1)
The results from PPC Tiger, Mac OS X 10.4.11, have to wait, my PowerBook runs on Leopard now…
--
Greetings
Pete <\
_\ O _
|o \ _\\_/-\='
_____________(_)|-(_) (_)___________________________________
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78562; Package
coreutils.
(Thu, 05 Jun 2025 13:19:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 78562 <at> debbugs.gnu.org (full text, mbox):
> Am 30.05.2025 um 18:46 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> touch -t 202505290000 a b
> gls -l --time-style=full a b
> echo 'b: a; echo ouch; false' >Makefile
> make
On PPC Mac OS X 10.4.11, Tiger, this sequence also produces:
make: `b' is up to date.
gls reports:
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 a
-rw-r--r-- 1 pete admin 0 2025-05-29 00:00:00.000000000 +0200 b
--
Greetings
Pete
There's something the technicians need to learn from the artists. If it isn't aesthetically pleasing, it's probably wrong.
This bug report was last modified 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.