bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext 0.10.37 msgfmt charset naming compatibility on Solaris 8


From: Bruno Haible
Subject: Re: gettext 0.10.37 msgfmt charset naming compatibility on Solaris 8
Date: Wed, 16 May 2001 21:24:05 +0200 (CEST)

Paul Eggert writes:

> >   1) Why doesn't Solaris iconv() not accept "ISO-8859-1" as a
> >      conversion name?
> 
> Beats me.  I'll file an enhancement request, and will mention the
> conversion names mentioned in charset.alias.

Good idea. The names every iconv() ought to support are 1. the IANA
names, 2. the MIME names (listed in the last column of
config.charset).

> > 1) An autoconf test which checks for each of the charsets listed in
> >    po.c
> >      a. under which name this charset is available,
> >      b. whether it converts according to the standard tables used
> >         by glibc and libiconv.
> >    Such a check shouldn't make the "configure" file three megabytes
> >    large, of course. I have more ideas on this step.
> 
> But this would require that the build machine have all the character
> set support that the runtime machine has.  It's quite common to build
> on English-only hosts, and then run on Japanese hosts.

If you build on an English-only host, the autoconf test shall know
that it can only rely on ASCII or perhaps ISO-8859-1, and must not
call the native iconv() with EUC-JP - because that hasn't been
verified to be reliable at autoconf time.

If you build on a Japanese host and then deploy on an English host,
the iconv wrapper would attempt to use EUC-JP but, upon failure return
from iconv_open, give the usual warning or error.

> How about instead modifying config.charset so that it will output the
> tables in question?  It's already outputting the forward mapping in a
> hard-coded way; it shouldn't be hard to modify it output the reverse
> mapping, for hosts where this works.  You already have to maintain
> config.charset anyway, so it wouldn't be much more work to maintain
> it after the change.

That would be twice as much maintenance work, for little gain. No.

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]