Bug #13423

gettext does not find the message catalogs of programs installed by the user

Added by Bruno Haible 19 days ago. Updated 19 days ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


The gettext() function in libc does not find the message catalogs of programs that a user has installed with a --prefix option. It only finds the message catalogs of programs that are installed by the OS (under /usr).

How to reproduce:
1. Unpack the attached hello.tar.gz.
2. tar xfz hello.tar.gz
3. cd hello
4. gcc -Wall hello.c -o hello
5. ./hello
Expected output: Bonjours les gamins!
Actual output: Hello guys!

A truss ./hello 2>&1 | fgrep command reveals that gettext() from libc is looking for

But packages that install GNU .mo files do so
1) in directories that are not specific to the locale encoding
(because .mo files are converted to the actual locale encoding
in memory, see usr/src/lib/libc/port/i18n/gettext_gnu.c function do_conv),
2) in directories that are not specific to the territory, if
that makes sense. For example, French is the same in France and
in most of Africa, therefore there is only one French message
catalog, and it is stored in <LOCALEDIR>/fr/LC_MESSAGES/<domain>.mo .

So, gettext() needs to try fallbacks
1) by removing the locale encoding suffix,
2) by removing the territory.

Solaris 11.0 to 11.3 gets this half right: it looks in

Solaris 11.4 gets it right: it looks in

The same change should be done in OpenIndiana.

Otherwise, the only workarounds are:
- The user who installs a program with --prefix=PREFIX has to create symlinks in PREFIX/share/locale/ (lots of symlinks!).
- Or install GNU gettext, and let the programs use gettext() from GNU libintl instead of from libc.

Setting NLSPATH is not a valid workaround, because POSIX says in :
"Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges."


hello.tar.gz (505 Bytes) hello.tar.gz Test case Bruno Haible, 2021-01-01 01:29 PM

Updated by Bruno Haible 19 days ago

The same bug exists in OmniOS release 2020-11-02.

Also available in: Atom PDF