From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9855 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [bug-gettext] AM_GNU_GETTEXT without referring internal symbols? Date: Thu, 7 Apr 2016 02:26:59 -0400 Message-ID: <20160407062659.GM21636@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1460010447 3382 80.91.229.3 (7 Apr 2016 06:27:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2016 06:27:27 +0000 (UTC) Cc: musl@lists.openwall.com, bug-gnu-gettext@gnu.org To: Masanori Ogino Original-X-From: musl-return-9868-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 07 08:27:20 2016 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 1ao3PR-000886-BO for gllmg-musl@m.gmane.org; Thu, 07 Apr 2016 08:27:17 +0200 Original-Received: (qmail 18154 invoked by uid 550); 7 Apr 2016 06:27:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18132 invoked from network); 7 Apr 2016 06:27:14 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9855 Archived-At: On Thu, Apr 07, 2016 at 02:34:01PM +0900, Masanori Ogino wrote: > 2016-04-07 11:26 GMT+09:00 Daiki Ueno : > > Masanori Ogino writes: > >> That is why I proposed to have a blacklist of "broken" implementations > >> as an option. > >> > >> AFAIK there have already been some blacklisting in autotools e.g. > >> checking the version of glibc to reject specific broken implementation > >> of a function. Thus, I think it's acceptable to use a blacklist. What > >> do you think about it? > > > > Yes, that sounds like a good idea. But I guess we then need to collect > > information about incompatible implementations. In this regard I'm > > actually not sure if the gettext-tools test coverage can be used as an > > indicator of compatibility. > > Indeed. > > > By the way, musl defines __GNU_GETTEXT_SUPPORTED_REVISION in the same > > way as glibc: > > > > #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 1 : -1) > > > > Is major = 1 + minor = 1 actually supported in musl? > > musl doesn't support "%Id" (major 1) IIRC. I suspect that musl > actually supports "system dependent segment" (minor 1) as the GNU > implementation does. > > On the other hand, glibc's definition is questionable too since it > seems that glibc's gettext implements major 1. The intent is that musl supports the _API_ fully, not the (IMO awful, and against the whole spirit of gettext) GNU implementation of sysdep strings as a segment of the mo file that's patched at runtime and wastes core in every process. Instead, msgfmt (there's a prototype version of the utility that does this, but it needs work) should generate all possible combinations of the expansion of the sysdep macros at mo generation time, and "sysdep" translations magically work with no runtime cost. At some point I want to prepare a patch for upstream msgfmt to do this but I haven't gotten around to it yet. I'm not sure what the %Id thing you're referring to is; can you point me to a description of it? Rich