Package: coreutils;
Reported by: Peter Dyballa <Peter_Dyballa <at> Web.DE>
Date: Fri, 23 May 2025 13:21:01 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
View this message in rfc822 format
From: Peter Dyballa <Peter_Dyballa <at> Web.DE> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: Pádraig Brady <P <at> draigBrady.com>, 78562 <at> debbugs.gnu.org Subject: bug#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 Date: Fri, 30 May 2025 11:38:55 +0200
> 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)
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.