From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9837 Path: news.gmane.org!not-for-mail From: Daiki Ueno Newsgroups: gmane.comp.gnu.gettext.bugs,gmane.linux.lib.musl.general Subject: Re: AM_GNU_GETTEXT without referring internal symbols? Date: Mon, 04 Apr 2016 11:23:55 +0900 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459736656 6856 80.91.229.3 (4 Apr 2016 02:24:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Apr 2016 02:24:16 +0000 (UTC) Cc: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org, bug-gnu-gettext-mXXj517/zsQ@public.gmane.org To: Masanori Ogino Original-X-From: bug-gettext-bounces+gcggb-bug-gettext=m.gmane.org-mXXj517/zsQ@public.gmane.org Mon Apr 04 04:24:07 2016 Return-path: Envelope-to: gcggb-bug-gettext@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1amuBS-0000AK-Pi for gcggb-bug-gettext@m.gmane.org; Mon, 04 Apr 2016 04:24:06 +0200 Original-Received: from localhost ([::1]:56143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amuBS-0004sF-55 for gcggb-bug-gettext@m.gmane.org; Sun, 03 Apr 2016 22:24:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amuBP-0004s4-1f for bug-gettext-mXXj517/zsQ@public.gmane.org; Sun, 03 Apr 2016 22:24:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amuBL-000261-RD for bug-gettext-mXXj517/zsQ@public.gmane.org; Sun, 03 Apr 2016 22:24:02 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amuBL-00025x-Ns; Sun, 03 Apr 2016 22:23:59 -0400 Original-Received: from du-a.org ([219.94.251.20]:34914 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1amuBK-0002xJ-O2; Sun, 03 Apr 2016 22:23:59 -0400 In-Reply-To: (Masanori Ogino's message of "Fri, 1 Apr 2016 21:56:34 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: bug-gettext-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for GNU gettext List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gettext-bounces+gcggb-bug-gettext=m.gmane.org-mXXj517/zsQ@public.gmane.org Original-Sender: bug-gettext-bounces+gcggb-bug-gettext=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.comp.gnu.gettext.bugs:1172 gmane.linux.lib.musl.general:9837 Archived-At: Hello, Masanori Ogino writes: > Now AM_GNU_GETTEXT uses _nl_msg_cat_cntr and _nl_expand_alias to check > whether the implementation is compatible with GNU gettext. However, > the symbols don't appear in libintl.h so it seems that they are not > part of the public API. > > Actually, musl libc implements libintl features and the score of > gettext-tools' testsuite is equal to that with the internal libintl, > using a modified AM_GNU_GETTEXT. > > The musl's libintl.h even defines __USE_GNU_GETTEXT and > __GNU_GETTEXT_SUPPORTED_REVISION, but it does not imitate private > symbols. > > I had checked the archive and I've found some discussions: > https://lists.gnu.org/archive/html/bug-gnu-utils/2006-03/msg00011.html > http://lists.gnu.org/archive/html/bug-gettext/2015-11/msg00015.html > > So, if the goal of the macro is check if the implementation is > compatible with GNU gettext, why don't we check the public API rather > than using internal symbols? Is it possible to check if the > implementation is not one of known "broken" implementations and/or it > is really compatible? I agree that it would be desirable, but doubt that it is possible (at least reliably), because: - For some reason, there is no public API to directly load arbitrary MO files and we need to mimic the behavior of translated applications: prepare a directory structure (e.g. DIR/fr/domain.mo), call bindtextdomain() for the directory, and finally call gettext(). - That requires that at least one non-POSIX locale is available on the system, to pick the translation. However, even if the system is glibc based, not all locales might be available thanks to sub-packaging (Fedora) or user configuration (Debian). So I suppose the only feasible option here is to somehow whitelist the implementations by checking macros or symbols. Does musl provides anything like that[1]? Regards, Footnotes: [1] https://sourceforge.net/p/predef/wiki/Libraries/ -- Daiki Ueno