[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150416003506.GT6817@brightrain.aerifal.cx>
Date: Wed, 15 Apr 2015 20:35:07 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: libintl: stubs or working functions
On Wed, Apr 15, 2015 at 09:18:16PM +0200, Felix Janda wrote:
> 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
Sadly m4 gives me a headache, so I haven't yet figured out what the
above code is doing.
> (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?
If the program actually needs a specific version of GNU gettext, then
it almost certainly does not (fully) work with musl's without also
using a fixed msgfmt utility.. The offending functionality is GNU
gettext's "SYSDEP strings" which conflict with the whole design of
gettext to use immutable memory-mapped strings in-place.
The problem they're trying to solve is that some translatable strings
contain formats from <inttypes.h> like PRIx64, etc. whose definitions
may vary from one system to another.
The recent GNU/glibc gettext these projects are trying to depend on
has a hideous hack to process variable substitutions in strings at
message catalog load time and produce per-process copies of the
patched-up strings. This is a waste of code size, runtime, and memory,
and it's quite simply an offense against any rational sensibilities.
For programs using this feature, the version of the msgfmt utility
from Sabotage Linux simply performs the mappings (all possible ones,
so the resulting .mo file works on any system) at po->mo compile time,
and then standard gettext behavior in musl and other non-GNU
implementations can handle the application's needs.
I'm not sure what's the right way to get rid of the assumption on the
app configure side that it needs GNU gettext, though.
Rich
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.
