[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA-4+jff5kRoyLA9eJnEy6yw_qXyHQZf=y+iOVMuzTmGexkEcA@mail.gmail.com>
Date: Thu, 26 May 2016 21:53:49 +0900
From: Masanori Ogino <masanori.ogino@...il.com>
To: musl@...ts.openwall.com
Cc: bug-gnu-gettext@....org
Subject: Re: Re: [bug-gettext] AM_GNU_GETTEXT without referring
internal symbols?
Hello Daiki,
2016-05-26 15:09 GMT+09:00 Daiki Ueno <ueno@....org>:
> Hello,
>
> Masanori Ogino <masanori.ogino@...il.com> writes:
>
>> 2016-04-07 11:26 GMT+09:00 Daiki Ueno <ueno@....org>:
>>> Masanori Ogino <masanori.ogino@...il.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!
--
Masanori Ogino
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
