From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7391 Path: news.gmane.org!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: libintl: stubs or working functions Date: Thu, 16 Apr 2015 19:15:51 +0200 Message-ID: <20150416171505.GA1264@euler> References: <20150415191815.GA5045@euler> <20150416003506.GT6817@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1429204739 2526 80.91.229.3 (16 Apr 2015 17:18:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Apr 2015 17:18:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7404-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 16 19:18:58 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YinRI-0003xT-RU for gllmg-musl@m.gmane.org; Thu, 16 Apr 2015 19:18:56 +0200 Original-Received: (qmail 16009 invoked by uid 550); 16 Apr 2015 17:18:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15937 invoked from network); 16 Apr 2015 17:18:12 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20150416003506.GT6817@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7391 Archived-At: 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 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