On Fri, 29 Feb 2008 10:53:24 +0100
Oliver Kiddle <okiddle@xxxxxxxxxxx> 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?
Von: bruno@xxxxxxxxx
Betreff: Re: [bug-gnu-libiconv] Solaris libiconv vs. GNU libiconv
in terms of 646
Datum: 28. Februar 2008 01:37:21 MEZ
An: dam@xxxxxxxxxxxxx, bug-gnu-libiconv@xxxxxxx
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>