Re: Solaris versus our NLS files

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 10.12.25 17:14, Tom Lane wrote:
>> Yeah, I've been wrestling with that question. The best idea
>> I have at the moment is to look at "locale -a" output to see
>> which country codes Solaris thinks there are for each language,
>> and duplicate that.

> I wonder how other gettext-using projects handle this on Solaris. Most
> of those will use a higher-level build system such as Automake or Meson,
> and I don't see any facilities there to expand languages into full
> locale names on installation. So either this is broken for everyone
> else, too, or perhaps this is typically addressed on the packaging level
> (or there is some other explanation we're not seeing yet). In either
> case, I doubt that fixing this locally in PostgreSQL is the most
> appropriate solution.

I suspect that the answer for most non-Solaris-specific projects has
been "use GNU gettext". I don't want to rely on that answer, though,
because it will break every one of our Solaris/illumos buildfarm
animals, all of which are linking to libc gettext:

checking for library containing bind_textdomain_codeset... none required

Now it does appear that they all have (portions of?) GNU gettext
installed:

checking for msgfmt... /usr/gnu/bin/msgfmt

and so does my OpenIndiana image, which apparently means that GNU
gettext is pulled in by "sudo pkg install build-essential", because
that's all I did to install stuff. So maybe we should just say we
don't support the libc flavor of gettext on that platform, which
would require figuring out how to force linking to libintl instead.
I can look into that if it seems like a more acceptable solution.
I'm worried though that it amounts to adding a new dependency on
that platform.

regards, tom lane