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

[Peter Dyballa via GNU coreutils Bug Reports]

> Am 30.05.2025 um 08:24 schrieb Paul Eggert <egg...@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)