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), with the Gnulib version listed in that commit. On cfarm104, "./configure && make" fails, outputting the attached log (compressed). The link fails because the GNU Tar Makefile.am is missing some library flags that will pull in CoreFoundation.
In the --disable-nls case:
$ nm src/tar | grep ' U ' | grep thread
U _pthread_mutex_lock
U _pthread_mutex_unlock
'pthread_create' is not among these symbols. So, GNU tar is really
still single-threaded. pthread_mutex_lock and pthread_mutex_unlock
are in libSystem.B.dylib, and they are probably well optimized for
the single-threaded case. So, why do you want to avoid them?
I don't mind those.
In the --enable-nls case:
- libintl depends on CoreFoundation, because that contains the
documented API for determining the "Regional Settings" the user
has made.
- CoreFoundation does create separate threads during initialization.
Blame Apple for that; don't blame GNU source code for it.
Something squirrelly is going on there. --enable-nls is supposed to be about translating messages (e.g., gettext), not about other aspects of internationalization (e.g., strftime, mbrtoc32). Merely adding fprintftime (which is a strftime-ish thing) shouldn't mean we need to do something extra involving translating messages.
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. This is better for GNU tar (one less dependency), but if fprintftime were used I wouldn't get that behavior, and I expect nstrftime would have similar problems (not sure about nstrftime-limited but it wasn't worth my time to investigate).
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.
make.log.gz
Description: application/gzip
