[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 May 2016 15:09:56 +0900
From: Daiki Ueno <ueno@....org>
To: Masanori Ogino <masanori.ogino@...il.com>
Cc: musl@...ts.openwall.com, bug-gnu-gettext@....org
Subject: Re: Re: [bug-gettext] AM_GNU_GETTEXT without referring internal symbols?
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?
Regards,
--
Daiki Ueno
View attachment "0001-m4-Rely-less-on-internal-symbols.patch" of type "text/x-patch" (3381 bytes)
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.
