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.