Fwd: [bug-gnu-libiconv] Solaris libiconv vs. GNU libiconv in terms of 646

[Dagobert Michelsen]

Hello,

Am 28.02.2008 um 01:37 schrieb Bruno Haible:
> What is standard in the realm of character encodings, is defined by  
> IANA,
> here:
>   http://www.iana.org/assignments/character-sets

I see.

> > The troubles from the zsh-people is best described at
> >     <http://www.zsh.org/mla/workers/2008/msg00271.html>
> > The ZSH-people are currently building a workaround, but
> > this whole situation should be better addresses in libiconv.
>
> This situation has been addressed in full generality - there is not  
> only
> Solaris and "646", there is also HP-UX and "hp15CN", and many others -
> in the gnulib module 'iconv_open', here:
>
>    http://www.gnu.org/software/gnulib/MODULES.html#module%3Diconv_open

There is A/IX, HPUX, Irix, OSF1, but no Solaris. Shouldn't there
be one or am I missing the point here?

>   - Regarding the recommendation to use Solaris iconv, I recommend the
>     opposite: Solaris iconv is known to crash in some situations.

I'd be happy to link everything against GNU libiconv if it
works. However, I don't understand what exactly you are
proposing to solve this Solaris-issue: Using the workaround
in every package or making a .gperf for Solaris? Or is there
already something which can simple be "turned on" on compilation
to allow 646-conversion to work?

> > Additionally, the "646-problem" on Solaris with libiconv
> > seems to be widely seen, e. g. here:
> >    <http://www.blastwave.org/mantis/view_bug_advanced_page.php?
> > f_id=0001849>
>
> This URL does not work for me. It shows a login screen, allowing an
> anonymous login. After this, no way to search a bug by number.

I guess you need an account there. Anyway, heres a snippet of the
relevant lines:

> It seems the reason for this is because Solaris cannot figure out  
> the UTF-8 conversion based on the native locale. Apparently, the  
> charset returned by nl_langinfo(CODESET) for Solaris is "646",  
> which is an undefined charset in the GNU version of libiconv (it  
> works in the native libiconv implementation). Since blastwave  
> packages are built against this GNU libiconv, it is suggested that  
> a patch be applied to this libiconv to associate the "646" charset  
> with the ascii charset in libiconv:
>
> Index: lib/encodings.def
> ===================================================================
> --- lib/encodings.def.orig 2006-06-09 11:28:55.861092000 -0500
> +++ lib/encodings.def 2006-06-09 12:19:58.081380000 -0500
> @@ -38,6 +38,7 @@
>
> DEFENCODING(( "US-ASCII", /* IANA */
> "ASCII", /* IANA, JDK 1.1 */
> + "646", /* Solaris */
> "ISO646-US", /* IANA */
> "ISO_646.IRV:1991", /* IANA */
> "ISO-IR-6", /* IANA */
>
> Most of this information was gleaned from other sources, via Trac's  
> own issue database. Links for these issues and the above patch as  
> found by the users of Trac are in the "Additional Information"  
> section of this bug.
> Steps To Reproduce
>
> Additional Information
> Details of this issue (as it applies to Trac) and its fix are able  
> to be found here:
> issue: http://trac.edgewall.org/ticket/2560
> fix for iconv: http://trac.edgewall.org/ticket/2560#comment:20
>
> More in-depth info here:
> http://marc.theaimsgroup.com/?l=apr-dev&m=114954995213823&w=2


Best regards

  -- Dagobert