Hi Paul,
Paul Eggert wrote:
> recent changes to Gnulib broke the GNU tar build on macOS
What do you mean by that? When I
1. check out GNU tar commit 453d903de916a9f705398152cec9db369b7d7bb8
(the last one before the fprintftime dependency removal),
2. run "./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR"
to get the newest gnulib,
3. create a tarball on a GNU/Linux system, through "make dist",
4. build that tarball on cfarm104.cfarm.net,
I get a nearly perfect build:
- With configure option '--disable-nls':
$ otool -L src/tar
src/tar:
/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)
- With configure option '--enable-nls':
$ otool -L src/tar
src/tar:
/Users/haible/lib/libintl.8.dylib (compatibility version 13.0.0,
current version 13.5.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1953.255.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)
- In both configurations, "make check" has only 1 test failure:
138: filename normalization FAILED (incr08.at:41)
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.
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?
Multithreading is normal libc functionality for 20-25 years now.
> I decided to change GNU tar to not use fprintftime.
That's a pity, that you remove functionality on all systems,
including GNU systems, because of a portability hassle on one particular
system.
> But also, if GNU tar is ever to count columns of output (something Bruno
> mentioned), it can't use fprintftime because fprintftime returns a byte
> count, not a column count.
Indeed, since the stdio FILE streams cannot be augmented with column-
tracking and padding functionality, one would need to call nstrftime
followed by mbswidth.
Bruno
