Paul Eggert wrote:
> On 2025-11-17 18:15, Bruno Haible wrote:
> > What do you mean by that? When I
> > 1. check out GNU tar commit 453d903de916a9f705398152cec9db369b7d7bb8
> > (the last one before the fprintftime dependency removal),
>
> That's the commit just after removing the fprintftime dependency, so it
> avoids the build problem I fixed.
>
> To reproduce the problem, use the previous GNU tar commit
> (0521528cdfbce4f00a2aa3b8623c916b257c9783)
Oops, thanks for pointing to my mistake.
Yes, with this commit, I reproduce the error. config.status has determined
this variable:
$ grep CoreFoundation config.status
S["INTL_MACOSX_LIBS"]="-Wl,-framework -Wl,CoreFoundation -Wl,-framework
-Wl,CoreServices"
and this link variable is needed by several Gnulib modules:
$ grep -rl INTL_MACOSX_LIBS modules/ | grep -v tests | sort
modules/fprintftime
modules/localename
modules/localename-unsafe
modules/localename-unsafe-limited
modules/nstrftime
modules/nstrftime-limited
modules/unicase/locale-language
> Merely adding
> fprintftime (which is a strftime-ish thing) shouldn't mean we need to do
> something extra involving translating messages.
The variable name 'INTL_MACOSX_LIBS' indeed used to mean "link dependencies
for use of libintl on macOS". Now it means "link dependencies for inter-
nationalization on macOS".
The use of gl_locale_name_unsafe on macOS, in strftime.c, is for the
non-Gregorian calendars. Maybe we can use a libc API, instead of a
CoreFoundation API, to determine whether a locale of Thailand, Iran, or
Ethiopia is in use? Much like your trick to determine the LC_CTYPE locale
category's encoding:
/* If DF BF decodes to 07FF, assume it is UTF-8. */
static char const utf07FF[2] = { 0xDF, 0xBF };
char32_t w;
mbstate_t mbstate = {0,};
if (mbrtoc32 (&w, utf07FF, 2, &mbstate) == 2 && w == 0x07FF)
return name_utf8;
If we assume that Thai, Farsi, and Amharic are mostly spoken in these
countries (and that users don't create locales like th_US.UTF-8), it
would be sufficient to test for the language:
$ cd glibc/localedata/locales; ls -1 th_* am_* fa_*
am_ET
fa_IR
th_TH
And testing for the language could be done by testing for the full
weekday name of, say, Monday, in that language. I.e. by calling the
system's strftime("%A") for a particular date.
This would get rid of this link dependency on macOS. Does that sound
reasonable?
> On cfarm104 with GNU tar's latest commit
> (28556dddae1aa6b802413d4945b18da5358e3460), otool -L src/tar doesn't
> pull in CoreFoundation regardless of whether one configures with
> --enable-nls or --disable-nls.
It doesn't directly. But with --enable-nls, CoreFoundation is among
the transitive dependencies:
$ otool -L src/tar
src/tar:
/Users/haible/lib/libintl.8.dylib (compatibility version 13.0.0,
current version 13.5.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version
7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1319.0.0)
$ otool -L /Users/haible/lib/libintl.8.dylib
/Users/haible/lib/libintl.8.dylib:
/Users/haible/lib/libintl.8.dylib (compatibility version 13.0.0,
current version 13.5.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version
7.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1953.255.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 1228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1319.0.0)
And it's actually necessary, as I said, in order to take into account
the user's "Regional Settings" values, when no environment variable
such as LC_ALL or LANG is set.
> I expect nstrftime would have similar problems (not sure about
> nstrftime-limited but it wasn't worth my time to investigate).
nstrftime-limited only deals with OpenBSD, AIX, Android.
> For GNU tar this issue is overkill, as it's fine to limit the format
> support to whatever macOS's strftime supports. That's why, when I
> stopped tar from using fprintftime, I didn't investigate nstrftime-limited.
Well, the native strftime() has some bugs, that we list in
doc/posix-functions/strftime.texi.
Bruno
