mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Masanori Ogino <masanori.ogino@gmail.com>
Cc: musl@lists.openwall.com, bug-gnu-gettext@gnu.org
Subject: Re: Re: [bug-gettext] AM_GNU_GETTEXT without referring internal symbols?
Date: Thu, 26 May 2016 15:36:58 -0400	[thread overview]
Message-ID: <20160526193658.GA21636@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAA-4+jff5kRoyLA9eJnEy6yw_qXyHQZf=y+iOVMuzTmGexkEcA@mail.gmail.com>

On Thu, May 26, 2016 at 09:53:49PM +0900, Masanori Ogino wrote:
> Hello Daiki,
> 
> 2016-05-26 15:09 GMT+09:00 Daiki Ueno <ueno@gnu.org>:
> > Hello,
> >
> > Masanori Ogino <masanori.ogino@gmail.com> writes:
> >
> >> 2016-04-07 11:26 GMT+09:00 Daiki Ueno <ueno@gnu.org>:
> >>> Masanori Ogino <masanori.ogino@gmail.com> 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.
> >
> > I was wondering if there is anything could be done in the upcoming
> > gettext release.  Let's go back to the original explanation by Bruno:
> > https://lists.gnu.org/archive/html/bug-gnu-utils/2006-03/msg00011.html
> > where he states two things:
> >
> > 1. The purpose of the checks are excluding incompatible implementations,
> >    e.g., NetBSD (around 1.5?) and Solaris 7
> >
> > 2. The __GNU_GETTEXT_SUPPORTED_REVISION macro is a recent addition
> >
> > In that case, I guess we could bypass the symbol checks if
> > __GNU_GETTEXT_SUPPORTED_REVISION is defined, as long as broken
> > implementations do not define it.
> >
> > How about the attached patch?
> 
> It looks essentially good to me. You can remove the "if test
> $gt_api_version -ge 3; then ... fi" part before where you modified too
> if it is not used anywhere else, I guess.
> 
> Thank you for working on!

I haven't tested it but the concept looks good to me too.

Rich


  reply	other threads:[~2016-05-26 19:36 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
     [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 [this message]
     [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=20160526193658.GA21636@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=bug-gnu-gettext@gnu.org \
    --cc=masanori.ogino@gmail.com \
    --cc=musl@lists.openwall.com \
    /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).