On 2022-10-29 23:47, Deborah Goldsmith wrote:
I just happened to have gettext installed on my system; it’s not a standard part of macOS. It would probably be best to compile it out by default on Darwin systems.
It's not compiled by default on Darwin; it's compiled only if the build host has <libintl.h>. From this thread: https://github.com/pyenv/pyenv/issues/1877 it appears that it's common for a macOS build host to have misconfigured copies of arm64 and x86_64 libraries - possibly because migration assistance copied over an old homebrew system, and possibly with different versions on x86_64 vs arm64 - and where <libintl.h> therefore compiles (because the same libintl.h works for multiple architectures and versions) but the resulting program doesn't link. My guess is that Gilmore has such a system and this broke zic linking, whereas you have a clean system where zic linked fine. What a mess, huh? To try to work around the problem, and partly in response to your suggestion, I installed the attached patch into the development repository on GitHub. Unfortunately, a downside of this patch is that zic by default now lacks internationalization support on macOS. This means user-friendly behavior like the following shell transcript, which is routine on GNU/Linux: $ export LC_ALL=fr_FR.utf8 $ echo "Cette entrée n'est pas valide." | zic - "entrée standard", ligne 1: Ligne d'entrée de type inconnu won't work on macOS by default. If you think the attached patch is headed in the wrong direction, I'll revert it and instead ask users like Gilmore with messed-up build hosts to build with 'make CFLAGS="-DHAVE_GETTEXT=0"', which they already have to do with 2022f.