Re: New uncompatible locale system with glibc2.2 ?
Changwoo Ryu <cwryu@debian.org> writes:
> Raphael Hertzog <rhertzog@hrnet.fr> writes:
>
> ...
> > Since glibc2.2 has been uploaded, the packages using gettext compiled with
> > glibc2.1 are no more able to output translated strings with diacritic
> > signs (eacute (é) and so on for french people for example) ... instead
> > we see "?" ...
> >
> > A simple recompile of the affected packages and it works again but it's a
> > pain ... it means all i18ned apps needs to be recompiled with glibc2.2
> > just to work correctly again.
> >
> > Does anybody know why it has to be this way ? Is there something else we
> > can do ? Is this a bug or a known problem that we can't bypass because of
> > a internal redesign or something like that ?
>
> I can't believe recompiling makes them work.. It's not such a
> problem.
>
> This problem occurs when a program (1) uses gettext, but (2) does not
> call proper setlocale() for LC_CTYPE (or LC_ALL, which includes
> LC_CTYPE). This is because that glibc does some charset conversion
> over the translated messages, so that the one .MO file could be used
> for all the locales that have only different charsets.
Ah, another case: using strerror() always returns the translated
string (if any). Without LC_CTYPE setting, strerror() prints question
marks.
> I don't know which one is buggy, glibc or the programs. glibc does
> not handle this situation. But anyway LC_MESSAGES depends on LC_CTYPE
> in some way.
Now I believe glibc is buggy...
--
Changwoo Ryu
Reply to: