Subject: Re: 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

From: Peter Dyballa <[email-masked]>
Date: Fri, 30 May 2025 11:38:55 +0200

> Am 30.05.2025 um 08:24 schrieb Paul Eggert <[email-masked]>:
> 
>> 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)