Re: libintl: stubs or working functions

[Felix Janda <felix.janda@posteo.de>]

On Thu, Mar 06, 2015 at 22:24:15PM GMT, Rich Felker wrote:
> On Thu, Mar 05, 2015 at 04:36:49PM +0700, Рысь wrote:
[snip]
> > * 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

http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/m4/gettext.m4#n159

(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.


https://lists.gnu.org/archive/html/bug-gnu-utils/2006-03/msg00011.html

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?

Thanks,
Felix