From: Peter Stephenson <pws@csr.com>
To: Dagobert Michelsen <dam@blastwave.org>, zsh-workers@sunsite.dk
Subject: Re: * Re: Failed tests of zsh 4.3.5 in Solaris 10 w/Sun Studio 12 CC
Date: Wed, 27 Feb 2008 11:29:30 +0000 [thread overview]
Message-ID: <200802271129.m1RBTVIC003639@news01.csr.com> (raw)
In-Reply-To: <18951.1204047420@thecus>
Oliver Kiddle wrote:
> Peter wrote:
> > > Is this an error from zsh or is this a bug in libiconv?
>
> It's actually better to avoid using libiconv and stick to the builtin
> iconv on Solaris. It handles 646 correctly. I always make a point of
> making sure it doesn't find GNU libiconv when compiling.
I've tried to take account of that below...
> > + if (!codessetstr || !*codsetstr ||
> > + !strcmp(codesetstr, "646"))
> > + codesetstr == "US-ASCII";
>
> Is the last line of this correct? Isn't it meant to be an assignment?
Yes, that was fixed by Dagobert.
> I would be inclined to wrap the whole thing inside #ifdef
> _libiconv_version because the problem only occurs when using GNU iconv
> instead of the Solaris builtin one.
And there's the reciprocal problem: some native Solaris iconv's (such as
the one I just tried in Solaris 8) don't support US-ASCII and other
obvious forms, they only support 646 etc, so we definitely need more
work.
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
and if that's set compiles in some fairly defensive code. I tried
this under Cygwin which uses libiconv.
Note this doesn't trigger if iconv is part of glibc, as under (most?)
Linux distributions.
Index: MACHINES
===================================================================
RCS file: /cvsroot/zsh/zsh/MACHINES,v
retrieving revision 1.5
diff -u -r1.5 MACHINES
--- MACHINES 21 May 2007 09:52:30 -0000 1.5
+++ MACHINES 27 Feb 2008 10:20:16 -0000
@@ -212,7 +212,11 @@
This may work, but the first username completion will be _very_
slow (as slow as in tcsh).
-Sun: Solaris 2.x, 8, 9
+Sun: Solaris 2.x, 8, 9, ...
+ It is recommended that the system library version of iconv()
+ be used rather than libiconv since there are incompatibilities
+ in the way codesets are named.
+
The UCB versions of the routines for reading directories are not
usable (the struct definitions are incompatible with the ones
assumed by zsh). The symptom of this is that globbed filenames in
Index: configure.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.ac,v
retrieving revision 1.92
diff -u -r1.92 configure.ac
--- configure.ac 3 Feb 2008 18:17:13 -0000 1.92
+++ configure.ac 27 Feb 2008 10:20:17 -0000
@@ -824,8 +824,13 @@
[ #include <iconv.h> ])
fi
fi
+AH_TEMPLATE([ICONV_FROM_LIBICONV],
+[Define to 1 if iconv() is linked from libiconv])
if test "x$ac_found_iconv" = xyes; then
AC_DEFINE(HAVE_ICONV, 1, [Define if you have the iconv() function.])
+ AC_TRY_LINK([#include <iconv.h>],
+ [int myversion = _libiconv_version],
+ AC_DEFINE(ICONV_FROM_LIBICONV), )
fi
dnl Check if iconv uses const in prototype declaration
Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.181
diff -u -r1.181 utils.c
--- Src/utils.c 26 Feb 2008 20:50:12 -0000 1.181
+++ Src/utils.c 27 Feb 2008 10:20:20 -0000
@@ -4880,15 +4880,32 @@
* If the code set isn't handled, we'd better
* assume it's US-ASCII rather than just failing
* hopelessly. Solaris has a weird habit of
- * returning 646.
+ * returning 646. This is handled by the
+ * native iconv(), but not by GNU iconv; what's
+ * more, some versions of the native iconv don't
+ * handle standard names like ASCII.
+ *
+ * This should only be a problem if there's a
+ * mismatch between the NLS and the iconv in use,
+ * which probably only means if libiconv is in use.
+ * We checked at configure time if our libraries
+ * pulled in _libiconv_version, which should be
+ * a good test.
*
* It shouldn't ever be NULL, but while we're
* being paranoid...
*/
- if (!codesetstr || !*codesetstr ||
- !strcmp(codesetstr, "646"))
+#ifdef ICONV_FROM_LIBICONV
+ if (!codesetstr || !*codesetstr)
codesetstr = "US-ASCII";
+#endif
cd = iconv_open(codesetstr, "UCS-4BE");
+#ifdef ICONV_FROM_LIBICONV
+ if (cd == (iconv_t)-1 && !strcmp(codesetstr, "646")) {
+ codesetstr = "US-ASCII";
+ cd = iconv_open(codesetstr, "UCS-4BE");
+ }
+#endif
if (cd == (iconv_t)-1) {
zerr("cannot do charset conversion (iconv failed)");
CHARSET_FAILED();
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
next prev parent reply other threads:[~2008-02-27 11:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-26 13:18 Dagobert Michelsen
2008-02-26 14:14 ` Peter Stephenson
2008-02-26 14:42 ` Dagobert Michelsen
2008-02-26 14:57 ` Peter Stephenson
2008-02-26 15:18 ` Dagobert Michelsen
2008-02-26 16:10 ` * " Peter Stephenson
2008-02-26 17:37 ` Oliver Kiddle
2008-02-27 11:29 ` Peter Stephenson [this message]
2008-02-27 16:16 ` Bart Schaefer
2008-02-29 9:53 ` Oliver Kiddle
2008-03-03 12:08 ` Peter Stephenson
2008-03-03 12:43 ` Dagobert Michelsen
2008-03-03 12:59 ` Peter Stephenson
2008-02-26 18:08 ` Peter Stephenson
2008-02-26 18:12 ` İsmail Dönmez
2008-02-26 19:19 ` Dagobert Michelsen
2008-02-26 19:47 ` Dagobert Michelsen
2008-02-26 20:42 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200802271129.m1RBTVIC003639@news01.csr.com \
--to=pws@csr.com \
--cc=dam@blastwave.org \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).