From: Masanori Ogino <masanori.ogino-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Daiki Ueno <ueno-mXXj517/zsQ@public.gmane.org>
Cc: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
bug-gnu-gettext-mXXj517/zsQ@public.gmane.org
Subject: Re: AM_GNU_GETTEXT without referring internal symbols?
Date: Mon, 4 Apr 2016 13:23:41 +0900 [thread overview]
Message-ID: <CAA-4+jcpfOXoYx1g_48M0B7punK7r2AOU7YU-V_pdQNGYcFmng@mail.gmail.com> (raw)
In-Reply-To: <m3h9fit8lg.fsf-ueno-mXXj517/zsQ@public.gmane.org>
Thank you for your reply, Daiki.
2016-04-04 11:23 GMT+09:00 Daiki Ueno <ueno-mXXj517/zsQ@public.gmane.org>:
> Hello,
>
> Masanori Ogino <masanori.ogino-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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).
OK, I understood now.
> 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]?
No, it doesn't on purpose. Here is the entry on this topic in the FAQ:
http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
Also, I'd like to point out some detailed explanations in a recent discussion:
http://www.openwall.com/lists/musl/2016/03/23/6
http://www.openwall.com/lists/musl/2016/03/23/7
http://www.openwall.com/lists/musl/2016/03/23/9
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?
--
Masanori Ogino
next prev parent reply other threads:[~2016-04-04 4:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 12:56 Masanori Ogino
[not found] ` <CAA-4+jeUF8c+Kmv0UQi0akMAtc2hmi3pC_8=nBNcsfuRcjSgNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-04 2:23 ` Daiki Ueno
[not found] ` <m3h9fit8lg.fsf-ueno-mXXj517/zsQ@public.gmane.org>
2016-04-04 4:23 ` Masanori Ogino [this message]
[not found] ` <CAA-4+jcpfOXoYx1g_48M0B7punK7r2AOU7YU-V_pdQNGYcFmng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-07 2:26 ` [musl] " Daiki Ueno
2016-04-07 5:34 ` Re: [bug-gettext] " Masanori Ogino
2016-04-07 6:26 ` Rich Felker
2016-04-07 7:12 ` Masanori Ogino
2016-04-07 10:57 ` Szabolcs Nagy
2016-04-07 13:53 ` Rich Felker
[not found] ` <CAA-4+jfbUEi1bBBP7iT2_9zaxyR+XvRb00yrWsoFj7iWiN3uUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-07 5:36 ` [musl] " Masanori Ogino
2016-05-26 6:09 ` Daiki Ueno
2016-05-26 12:53 ` Re: [bug-gettext] " Masanori Ogino
2016-05-26 19:36 ` Rich Felker
[not found] ` <20160526193658.GA21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
2016-05-27 8:48 ` [musl] " Daiki Ueno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA-4+jcpfOXoYx1g_48M0B7punK7r2AOU7YU-V_pdQNGYcFmng@mail.gmail.com \
--to=masanori.ogino-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=bug-gnu-gettext-mXXj517/zsQ@public.gmane.org \
--cc=musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org \
--cc=ueno-mXXj517/zsQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).