Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Apr 2015 21:18:16 +0200
From: Felix Janda <>
Subject: Re: libintl: stubs or working functions

On Thu, Mar 06, 2015 at 22:24:15PM GMT, Rich Felker wrote:
> On Thu, Mar 05, 2015 at 04:36:49PM +0700, Рысь wrote:
> > * Did I understand that right that I do not need GNU gettext anymore and
> >   I can use musl's interface for that?
> Yes, modulo some GNU software (coreutils for example) that probes for
> glibc/gnu-libintl internals at configure time and depends on
> poorly-designed and undocumented features (SYSDEP strings). These
> programs will not work without either GNU libintl or patching out the
> bad parts of configure and using a version of msgfmt that works around
> the need for SYSDEP strings. I believe the one from sabotage
> gettext-tiny does.

I would like to see what it takes to fix the autoconf tests. The problem
is the macro AM_GNU_GETTEXT with the check

(It looks for the internal symbols _nl_msg_cat_cntr and _nl_domain_bindings
instead of relying on __GNU_GETTEXT_SUPPORTED_REVISION().)
debian code search suggests that quite a lot of projects use this macro.

gives some reasoning for the unportable tests:

* _GNU_GETTEXT_SUPPORTED_REVISION() was only introduced in gettext 0.10.xx
* _GNU_GETTEXT_SUPPORTED_REVISION() of glibc says that it does not support
  major revision 1 although it does

I would like to ask the gettext developers for an additional test
"for GNU gettext in libc", which fails if __GLIBC__ uses
_GNU_GETTEXT_SUPPORTED_REVISION and can only improve the previous test result.

Any comments on this or alternative approaches?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.