[tz] Errors compiling 2022f on macOS

Guy Harris gharris at sonic.net
Sun Oct 30 23:42:37 UTC 2022


On Oct 30, 2022, at 4:16 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 2022-10-30 13:57, Guy Harris wrote:
>> That statement may also hold true for some other UN*Xes.
> 
> My impression is that users of NetBSD, OpenBSD etc. are less likely to run into this problem, because they don't have the complication of configuration issues inherent to macOS's brew-based system that is combined with automatic migration and multiple-architecture binaries and libraries.

The statement to which I was referring is

> Unfortunately, a downside of macOS not providing an implementation of the gettext API (the first implementation of which was, I think, in Solaris) is that zic by default lacks internationalization support on macOS.

I.e., the only *BSD on which you'll get internationalization by default is NetBSD; the others won't give you libintl out of the box, just as macOS won't - you'd have to install it yourself.

So you'll get

	$ echo "Ceci n'est pas une pipe." | LC_ALL=fr_FR.utf8 zic -
	"standard input", line 1: input line of unknown type
	$ echo "Ceci n'est pas une pipe." | LC_ALL=fr_FR.UTF-8 zic -
	"standard input", line 1: input line of unknown type

with the built-in zic, just as you will with the zic that ships with macOS, and you'll get that with a zic you compile from source unless you have installed libintl.

(And you'll probably also need a version of the tzcode that has .pc files and installs them.  I'm not seeing any files with translations for "standard input" or "input line of unknown type" in the current Git repository for tz.)

I.e., I'm not seeing "versions of zic that a user builds from source, on a system with libintl installed, will, by default, now lack internationalization support on macOS" as a change that will, in practice, disadvantage many people.


More information about the tz mailing list