Re: [bug-gettext] [musl] Re: AM_GNU_GETTEXT without referring internal symbols?

[Rich Felker]

On Thu, Apr 07, 2016 at 02:34:01PM +0900, Masanori Ogino wrote:
> 2016-04-07 11:26 GMT+09:00 Daiki Ueno <address@hidden>:
> > Masanori Ogino <address@hidden> 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.
> 
> > By the way, musl defines __GNU_GETTEXT_SUPPORTED_REVISION in the same
> > way as glibc:
> >
> >   #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 1 : -1)
> >
> > Is major = 1 + minor = 1 actually supported in musl?
> 
> musl doesn't support "%Id" (major 1) IIRC. I suspect that musl
> actually supports "system dependent segment" (minor 1) as the GNU
> implementation does.
> 
> On the other hand, glibc's definition is questionable too since it
> seems that glibc's gettext implements major 1.

The intent is that musl supports the _API_ fully, not the (IMO awful,
and against the whole spirit of gettext) GNU implementation of sysdep
strings as a segment of the mo file that's patched at runtime and
wastes core in every process. Instead, msgfmt (there's a prototype
version of the utility that does this, but it needs work) should
generate all possible combinations of the expansion of the sysdep
macros at mo generation time, and "sysdep" translations magically work
with no runtime cost. At some point I want to prepare a patch for
upstream msgfmt to do this but I haven't gotten around to it yet.

I'm not sure what the %Id thing you're referring to is; can you point
me to a description of it?

Rich