[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150416171505.GA1264@euler>
Date: Thu, 16 Apr 2015 19:15:51 +0200
From: Felix Janda <felix.janda@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: Re: libintl: stubs or working functions
Rich Felker wrote:
> 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.
As I understand applications need to pass 'need-formatstring-macros' to
the AM_GNU_GETTEXT macro to request this functionality. But with debian
code search I couldn't find any program doing that...
The macro distinguishes three gettext apis. gt_api_version is 1 for the
basic version. For the ngettext functions gt_api_version>=2 is necessary
and for these "SYSDEP strings" gt_api_version>=3 is necessary.
As I understand musl has gt_api_version=2. Is that right?
To test for the api version AM_GNU_GETTEXT checks in all cases for
bindtextdomain, gettext, _nl_msg_cat_cntr and _nl_domain_bindings. For
gt_api_version>=2 it checks for ngettext and for gt_api_version>=3 it
does something with __GNU_GETTEXT_SUPPORTED_REVISION we won't need to
care about.
So for musl the test gives obviously the wrong result.
I guess that we don't want to export symbols _nl_*.
What I would now like to ask upstream is to put the _nl_* stuff behind
an #ifdef __GLIBC__ ...
Felix
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.
