Re: * Re: Failed tests of zsh 4.3.5 in Solaris 10 w/Sun Studio 12 CC

[Dagobert Michelsen <dam@blastwave.org>]

Hi,

Am 03.03.2008 um 13:08 schrieb Peter Stephenson:
> On Fri, 29 Feb 2008 10:53:24 +0100
> Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>> Peter wrote:
>>> The following is the best I've got:  it tests for _libiconv_version
>>> (which should be an external variable and hence tell us whether  
>>> we're
>>> actually linking against libiconv, whatever the header is) in  
>>> configure
>>
>> I'd have thought the AC_CHECK_DECL for _libiconv_version as used  
>> already
>> earlier in configure.ac is a sufficient test. If you try to  
>> compile zsh
>> with the iconv header file not matching what it links against, you  
>> get
>> bigger problems and it doesn't compile at all. In fact, there is
>> _LIBICONV_VERSION which is a #define so you could #ifdef that.
>
> I wanted to be safe about that and as far as I can tell checking if  
> we get
> _libiconv_version linked in should do that, right?

I posted the libiconv-issues on the libiconv-list and got the
following reply for reference:

> 	Von: 	  bruno@clisp.org
> 	Betreff: 	Re: [bug-gnu-libiconv] Solaris libiconv vs. GNU libiconv  
> in terms of 646
> 	Datum: 	28. Februar 2008 01:37:21 MEZ
> 	An: 	  dam@blastwave.org, bug-gnu-libiconv@gnu.org
>
> Hello,
>
> Dagobert Michelsen wrote:
>
>> I am currently packaging zsh for Solaris when I noticed
>> some failing tests due to problems with libiconv.
>> It looks like Solaris uses 646 as standard which is
>> known to Solaris libiconv but not GNU libiconv.
>>
>
> Yes, this is a known problem. Solaris uses "646" to denote the ASCII
> encoding, and GNU libiconv does not.
>
> What is standard in the realm of character encodings, is defined by  
> IANA,
> here:
>   http://www.iana.org/assignments/character-sets
>
>
>> I already found this in the notes:
>>
>>    Q: Support encodings mentioned in RFC 1345 ?
>>    A: No, they are not in use any more. Supporting ISO-646 variants
>> is pointless
>>       since ISO-8859-* have been adopted.
>>
>
> The issue is actually slightly different. The encoding itself is well
> supported by both Solaris iconv and GNU libiconv. Only the name used
> by Solaris is a fantasy name.
>
>
>> 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
>
> Regarding the workaround that you are doing:
>
>   - The idea to use "US-ASCII" for GNU libiconv but "646" for  
> Solaris iconv
>     is right.
>
>   - Instead of a configure-time test you can also use a simpler  
> compile-time
>     test:
>
>       #ifdef _LIBICONV_VERSION
>         /* using GNU libiconv */
>       #else
>         /* using the native system iconv */
>         #ifdef __sun
>           /* using the Solaris iconv */
>         #else
>           /* other systems */
>         #endif
>       #endif
>
>   - Regarding the recommendation to use Solaris iconv, I recommend the
>     opposite: Solaris iconv is known to crash in some situations.
>
> Bruno
>
> PS: This mail should appear as
> <http://lists.gnu.org/archive/html/bug-gnu-libiconv/2008-02/ 
> msg00003.html>



Best regards

   -- Dagobert