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

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

[Dagobert Michelsen]

Hi,

I am building zsh 4.3.5 on Solaris 10 x86 with the
Sun Studio 12 compiler and I have some failed tests
in the teststuite:

  ==> Running make test in work/dam-thor.d/zsh-4.3.5
gmake[1]: Entering directory `/export/medusa/dam/trunk/devel/zsh/work/ 
dam-thor.d/zsh-4.3.5'
cd Test ; gmake check
gmake[2]: Entering directory `/export/medusa/dam/trunk/devel/zsh/work/ 
dam-thor.d/zsh-4.3.5/Test'
if test -n "cc"; then \
           cd .. && DESTDIR= \
           gmake MODDIR=`pwd`/Test/Modules install.modules > /dev/ 
null; \
         fi
if ZTST_testlist="`for f in ./*.ztst; \
            do echo $f; done`" \
          ZTST_srcdir="." \
          ZTST_exe=../Src/zsh \
          ../Src/zsh +Z -f ./runtests.zsh; then \
          stat=0; \
         else \
          stat=1; \
         fi; \
         rm -rf Modules .zcompdump; \
         exit $stat
./A01grammar.ztst: starting.
This test hangs the shell when it fails...
./A01grammar.ztst: all tests successful.
./A02alias.ztst: starting.
./A02alias.ztst: all tests successful.
./A03quoting.ztst: starting.
Test ./A03quoting.ztst failed: bad status 1, expected 0 from:
   print '<\u0041>'
   printf '%s\n' $'<\u0042>'
   print '<\u0043>'
   printf '%s\n' $'<\u0044>'
Error output:
(eval):1: cannot do charset conversion
Was testing: \u in both print and printf
./A03quoting.ztst: test failed.
./A04redirect.ztst: starting.
./A04redirect.ztst: all tests successful.
./A05execution.ztst: starting.
./A05execution.ztst: all tests successful.
./A06assign.ztst: starting.
./A06assign.ztst: all tests successful.
./B01cd.ztst: starting.
./B01cd.ztst: all tests successful.
./B02typeset.ztst: starting.
./B02typeset.ztst: all tests successful.
./B03print.ztst: starting.
./B03print.ztst: all tests successful.
./B04read.ztst: starting.
./B04read.ztst: all tests successful.
./C01arith.ztst: starting.
./C01arith.ztst: all tests successful.
./C02cond.ztst: starting.
Warning: not testing [[ -N file ]] (not supported with NFS)
Test ./C02cond.ztst failed: bad status 1, expected 0 from:
   [[ newnewnew -nt zerolength && ! (unmodified -nt zerolength) ]]
Was testing: -nt cond
./C02cond.ztst: test failed.
./C03traps.ztst: starting.
This test takes at least three seconds...
This test, too, takes at least three seconds...
Another test that takes three seconds
./C03traps.ztst: all tests successful.
./C04funcdef.ztst: starting.
./C04funcdef.ztst: all tests successful.
./D01prompt.ztst: starting.
./D01prompt.ztst: all tests successful.
./D02glob.ztst: starting.
./D02glob.ztst: all tests successful.
./D03procsubst.ztst: starting.
./D03procsubst.ztst: all tests successful.
./D04parameter.ztst: starting.
./D04parameter.ztst: all tests successful.
./D05array.ztst: starting.
./D05array.ztst: all tests successful.
./D06subscript.ztst: starting.
./D06subscript.ztst: all tests successful.
./D07multibyte.ztst: starting.
Testing multibyte with locale en_US.UTF-8
*** /tmp/zsh.ztst.out.19793     Tue Feb 26 08:06:28 2008
--- /tmp/zsh.ztst.tout.19793    Tue Feb 26 08:06:28 2008
***************
*** 1,4 ****
! OK
! OK
! OK
! OK
--- 1,4 ----
! Failed: no error message and no question mark
! Failed: no error message and no question mark
! Failed: no error message and no question mark
! Failed: no error message and no question mark
Test ./D07multibyte.ztst failed: output differs from expected as  
shown above for:
   testfn() { (LC_ALL=C; print $'\u00e9') }
   repeat 4 testfn 2>&1 | while read line; do
     if [[ $line = *"character not in range"* ]]; then
       print OK
     elif [[ $line = "?" ]]; then
       print OK
     else
       print Failed: no error message and no question mark
     fi
   done
   true
Was testing: error handling in Unicode quoting
./D07multibyte.ztst: test failed.
./D08cmdsubst.ztst: starting.
./D08cmdsubst.ztst: all tests successful.
./E01options.ztst: starting.
This test hangs the shell when it fails...
./E01options.ztst: all tests successful.
./E02xtrace.ztst: starting.
./E02xtrace.ztst: all tests successful.
./V01zmodload.ztst: starting.
./V01zmodload.ztst: all tests successful.
./V02zregexparse.ztst: starting.
./V02zregexparse.ztst: all tests successful.
./V03mathfunc.ztst: starting.
./V03mathfunc.ztst: all tests successful.
./V04features.ztst: starting.
./V04features.ztst: all tests successful.
./V05styles.ztst: starting.
./V05styles.ztst: all tests successful.
./Y01completion.ztst: starting.
./Y01completion.ztst: all tests successful.
./Y02compmatch.ztst: starting.
./Y02compmatch.ztst: all tests successful.
./Y03arguments.ztst: starting.
./Y03arguments.ztst: all tests successful.
**************************************
29 successful test scripts, 3 failures, 0 skipped
**************************************
gmake[2]: *** [check] Error 1
gmake[2]: Leaving directory `/export/medusa/dam/trunk/devel/zsh/work/ 
dam-thor.d/zsh-4.3.5/Test'
gmake[1]: *** [test] Error 2
gmake[1]: Leaving directory `/export/medusa/dam/trunk/devel/zsh/work/ 
dam-thor.d/zsh-4.3.5'
gmake: *** [test-work/dam-thor.d/zsh-4.3.5/Makefile] Error 2


Invocation was
   $ ./configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/ 
opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec -- 
datadir=/opt/csw/share --sysconfdir=/opt/csw/etc --sharedstatedir=/ 
opt/csw/share --localstatedir=/opt/csw/var --libdir=/opt/csw/lib -- 
infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/ 
opt/csw/share/man --enable-maildir-support --enable-fndir=/opt/csw/ 
share/zsh/functions --enable-pcre


Best regards

   -- Dagobert Michelsen

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

[Peter Stephenson]

On Tue, 26 Feb 2008 14:18:14 +0100
Dagobert Michelsen <dam@blastwave.org> wrote:
> I am building zsh 4.3.5 on Solaris 10 x86 with the
> Sun Studio 12 compiler and I have some failed tests
> in the teststuite:
>...
> ./A03quoting.ztst: starting.
> Test ./A03quoting.ztst failed: bad status 1, expected 0 from:
>    print '<\u0041>'
>    printf '%s\n' $'<\u0042>'
>    print '<\u0043>'
>    printf '%s\n' $'<\u0044>'
> Error output:
> (eval):1: cannot do charset conversion
>...
> ./D07multibyte.ztst: starting.
> Testing multibyte with locale en_US.UTF-8
> *** /tmp/zsh.ztst.out.19793     Tue Feb 26 08:06:28 2008
> --- /tmp/zsh.ztst.tout.19793    Tue Feb 26 08:06:28 2008
> ***************
> *** 1,4 ****
> ! OK
> ! OK
> ! OK
> ! OK
> --- 1,4 ----
> ! Failed: no error message and no question mark
> ! Failed: no error message and no question mark
> ! Failed: no error message and no question mark
> ! Failed: no error message and no question mark
> Test ./D07multibyte.ztst failed: output differs from expected as  

This means the it hasn't found either iconv or any other library to do
character conversion.  (The error message is suppressed in the second case
but there's a good chance it's the same error.)  The shell has two basic
ways of doing this:

(i) compile environment directly supports ISO 10646
(ii) libraries support nl_langinfo(CODESET) and
     (a) the current locale uses UTF-8 so the shell
         can do a trivial conversion to UTF-8.
     (b) iconv() is available in -liconv.

(i) or (ii) are handled at compile time.  The choice between (ii)(a) and
(ii)(b) is handled at run time so long as nl_langinfo(CODESET) is
available.  I don't think (ii)(a) applies in these tests, so this
presumably means both that the environment doesn't support ISO 10646, and
that iconv wasn't found.

It might for developers' purposes (this doesn't affect you directly except
as far as bug reports go) be useful to distinguish what failed...

Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.176
diff -u -r1.176 utils.c
--- Src/utils.c	25 Jan 2008 16:48:23 -0000	1.176
+++ Src/utils.c	26 Feb 2008 14:09:43 -0000
@@ -4877,7 +4877,7 @@
 
     	    	    cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");
 		    if (cd == (iconv_t)-1) {
-			zerr("cannot do charset conversion");
+			zerr("cannot do charset conversion (iconv failed)");
 			CHARSET_FAILED();
 		    }
                     count = iconv(cd, &inptr, &inbytes, &t, &outbytes);
@@ -4889,12 +4889,12 @@
 		    if ((how & GETKEY_UPDATE_OFFSET) && s - sstart < *misc)
 			(*misc) += count;
 #   else
-                    zerr("cannot do charset conversion");
+                    zerr("cannot do charset conversion (iconv not available)");
 		    CHARSET_FAILED();
 #   endif
 		}
 #  else
-                zerr("cannot do charset conversion");
+                zerr("cannot do charset conversion (NLS not supported)");
 		CHARSET_FAILED();
 #  endif
 # endif

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

[Dagobert Michelsen]

Hi Peter,

first, thanks for the effort. I have applied the patch
and reran the testsuite.

Am 26.02.2008 um 15:14 schrieb Peter Stephenson:
> On Tue, 26 Feb 2008 14:18:14 +0100
> Dagobert Michelsen <dam@blastwave.org> wrote:
>> I am building zsh 4.3.5 on Solaris 10 x86 with the
>> Sun Studio 12 compiler and I have some failed tests
>> in the teststuite:
>> ...
>> ./A03quoting.ztst: starting.
>> Test ./A03quoting.ztst failed: bad status 1, expected 0 from:
>>    print '<\u0041>'
>>    printf '%s\n' $'<\u0042>'
>>    print '<\u0043>'
>>    printf '%s\n' $'<\u0044>'
>> Error output:
>> (eval):1: cannot do charset conversion

./A03quoting.ztst: starting.
Test ./A03quoting.ztst failed: bad status 1, expected 0 from:
   print '<\u0041>'
   printf '%s\n' $'<\u0042>'
   print '<\u0043>'
   printf '%s\n' $'<\u0044>'
Error output:
(eval):1: cannot do charset conversion (iconv failed)
Was testing: \u in both print and printf

>> ...
>> ./D07multibyte.ztst: starting.
>> Testing multibyte with locale en_US.UTF-8
>> *** /tmp/zsh.ztst.out.19793     Tue Feb 26 08:06:28 2008
>> --- /tmp/zsh.ztst.tout.19793    Tue Feb 26 08:06:28 2008
>> ***************
>> *** 1,4 ****
>> ! OK
>> ! OK
>> ! OK
>> ! OK
>> --- 1,4 ----
>> ! Failed: no error message and no question mark
>> ! Failed: no error message and no question mark
>> ! Failed: no error message and no question mark
>> ! Failed: no error message and no question mark
>> Test ./D07multibyte.ztst failed: output differs from expected as

./D07multibyte.ztst: starting.
Testing multibyte with locale en_US.UTF-8
*** /tmp/zsh.ztst.out.12712     Tue Feb 26 09:35:42 2008
--- /tmp/zsh.ztst.tout.12712    Tue Feb 26 09:35:42 2008
***************
*** 1,4 ****
! OK
! OK
! OK
! OK
--- 1,4 ----
! Failed: no error message and no question mark
! Failed: no error message and no question mark
! Failed: no error message and no question mark
! Failed: no error message and no question mark
Test ./D07multibyte.ztst failed: output differs from expected as  
shown above for:
   testfn() { (LC_ALL=C; print $'\u00e9') }
   repeat 4 testfn 2>&1 | while read line; do
     if [[ $line = *"character not in range"* ]]; then
       print OK
     elif [[ $line = "?" ]]; then
       print OK
     else
       print Failed: no error message and no question mark
     fi
   done
   true
Was testing: error handling in Unicode quoting


> This means the it hasn't found either iconv or any other library to do
> character conversion.  (The error message is suppressed in the  
> second case
> but there's a good chance it's the same error.)  The shell has two  
> basic
> ways of doing this:
>
> (i) compile environment directly supports ISO 10646
> (ii) libraries support nl_langinfo(CODESET) and
>      (a) the current locale uses UTF-8 so the shell
>          can do a trivial conversion to UTF-8.
>      (b) iconv() is available in -liconv.
>
> (i) or (ii) are handled at compile time.  The choice between (ii) 
> (a) and
> (ii)(b) is handled at run time so long as nl_langinfo(CODESET) is
> available.  I don't think (ii)(a) applies in these tests, so this
> presumably means both that the environment doesn't support ISO  
> 10646, and
> that iconv wasn't found.

At least the dynamic binding is working:

thor% ldd work/dam-thor.d/zsh-4.3.5/Src/zsh
         libpcre.so.0 =>  /opt/csw/lib/i386/libpcre.so.0
         libiconv.so.2 =>         /opt/csw/lib/i386/libiconv.so.2
         libsocket.so.1 =>        /usr/lib/libsocket.so.1
         libdl.so.1 =>    /usr/lib/libdl.so.1
         libncurses.so.5 =>       /opt/csw/lib/i386/libncurses.so.5
         libm.so.1 =>     /usr/lib/libm.so.1
         libc.so.1 =>     /usr/lib/libc.so.1
         libnsl.so.1 =>   /usr/lib/libnsl.so.1
         libmp.so.2 =>    /usr/lib/libmp.so.2

It may be of interest that I am doing a "package build" with
DESTDIR installation as following:

cd work/dam-thor.d/zsh-4.3.5 && prefix="/opt/csw" exec_prefix="/opt/ 
csw" bindir="/opt/csw/bin" optbindir="/opt/csw/bin/i386" sbindir="/ 
opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share"  
sysconfdir="/opt/csw/etc" sharedstatedir="/opt/csw/share"  
localstatedir="/opt/csw/var" libdir="/opt/csw/lib" optlibdir="/opt/ 
csw/lib/i386" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/ 
emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/ 
man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS=" - 
I/export/medusa/dam/build/build.5.8-i386/opt/csw/include -I/opt/csw/ 
include" CFLAGS="-I/opt/csw/include/ncurses -xO3 -xtarget=generic - 
xarch=generic -I/export/medusa/dam/build/build.5.8-i386/opt/csw/ 
include -I/opt/csw/include " CXXFLAGS="-xO3 -xtarget=generic - 
xarch=generic -I/export/medusa/dam/build/build.5.8-i386/opt/csw/ 
include -I/opt/csw/include" LDFLAGS="  -L/export/medusa/dam/build/ 
build.5.8-i386/opt/csw/lib -L/opt/csw/lib" ASFLAGS="" OPTFLAGS="-xO3 - 
xtarget=generic -xarch=generic" CC="cc" CXX="CC" LD_OPTIONS="-R/opt/ 
csw/lib/\$ISALIST -R/opt/csw/lib" CC_HOME="/opt/studio/SOS11/ 
SUNWspro" CC_VERSION="Sun C 5.8 Patch 121016-07 2007/10/03"  
CXX_VERSION="Sun C++ 5.8 Patch 121018-11 2007/05/02" VENDORNAME=""  
VENDORSTAMP="" GARCH="i386" GAROSREL="5.8" GARPACKAGE="zsh"  
PKG_CONFIG_PATH="/export/medusa/dam/build/build.5.8-i386/opt/csw/lib/ 
pkgconfig:/opt/csw/lib/pkgconfig:" DESTDIR="/export/medusa/dam/build/ 
build.5.8-i386" ./configure --prefix=/opt/csw --exec_prefix=/opt/csw  
--bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/ 
libexec --datadir=/opt/csw/share --sysconfdir=/opt/csw/etc -- 
sharedstatedir=/opt/csw/share --localstatedir=/opt/csw/var --libdir=/ 
opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/ 
include --mandir=/opt/csw/share/man --enable-maildir-support --enable- 
fndir=/opt/csw/share/zsh/functions --enable-pcre

zsh configuration
-----------------
zsh version               : 4.3.5
host operating system     : i386-pc-solaris2.8
source code location      : .
compiler                  : cc
preprocessor flags        :  -I/export/medusa/dam/build/build.5.8- 
i386/opt/csw/include -I/opt/csw/include -I/opt/csw/include
executable compiler flags : -I/opt/csw/include/ncurses -xO3 - 
xtarget=generic -xarch=generic -I/export/medusa/dam/build/build.5.8- 
i386/opt/csw/include -I/opt/csw/include
module compiler flags     : -I/opt/csw/include/ncurses -xO3 - 
xtarget=generic -xarch=generic -I/export/medusa/dam/build/build.5.8- 
i386/opt/csw/include -I/opt/csw/include  -KPIC
executable linker flags   :   -L/export/medusa/dam/build/build.5.8- 
i386/opt/csw/lib -L/opt/csw/lib
module linker flags       :   -L/export/medusa/dam/build/build.5.8- 
i386/opt/csw/lib -L/opt/csw/lib  -G
library flags             : -L/opt/csw/lib -lpcre -liconv -lsocket - 
ldl -lncurses -lm  -lc
installation basename     : zsh
binary install path       : /opt/csw/bin
man page install path     : /opt/csw/share/man
info install path         : /opt/csw/share/info
functions install path    : /opt/csw/share/zsh/functions
See config.modules for installed modules and functions.


If I can do anything to help resolving these testing issues let me know.

Thanks!

   -- Dagobert Michelsen

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

[Peter Stephenson]

On Tue, 26 Feb 2008 15:42:19 +0100
Dagobert Michelsen <dam@blastwave.org> wrote:
> Hi Peter,
> 
> first, thanks for the effort. I have applied the patch
> and reran the testsuite.
> ./A03quoting.ztst: starting.
> Test ./A03quoting.ztst failed: bad status 1, expected 0 from:
>    print '<\u0041>'
>    printf '%s\n' $'<\u0042>'
>    print '<\u0043>'
>    printf '%s\n' $'<\u0044>'
> Error output:
> (eval):1: cannot do charset conversion (iconv failed)
> Was testing: \u in both print and printf

Weird... that's the variant I wasn't expecting since it implies
a run time failure in iconv, and not a dynamical link failure, either.
That means this call failed (Src/utils.c:4878 in the current source):

    	    	    cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");
		    if (cd == (iconv_t)-1) {
			zerr("cannot do charset conversion (iconv failed)");
			CHARSET_FAILED();
		    }

Any idea if your iconv supports UCS-4BE?  GNU iconv will tell you with
"iconv --list", but if you have a Solaris variant it's likely to be
different.  Otherwise, could nl_langinfo(CODESET) not be returning
anything?

-- 
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

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

[Dagobert Michelsen]

Hi Peter,

Am 26.02.2008 um 15:57 schrieb Peter Stephenson:
> On Tue, 26 Feb 2008 15:42:19 +0100
> Dagobert Michelsen <dam@blastwave.org> wrote:
>> first, thanks for the effort. I have applied the patch
>> and reran the testsuite.
>> ./A03quoting.ztst: starting.
>> Test ./A03quoting.ztst failed: bad status 1, expected 0 from:
>>    print '<\u0041>'
>>    printf '%s\n' $'<\u0042>'
>>    print '<\u0043>'
>>    printf '%s\n' $'<\u0044>'
>> Error output:
>> (eval):1: cannot do charset conversion (iconv failed)
>> Was testing: \u in both print and printf
>
> Weird... that's the variant I wasn't expecting since it implies
> a run time failure in iconv, and not a dynamical link failure, either.
> That means this call failed (Src/utils.c:4878 in the current source):
>
>     	    	    cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");
> 		    if (cd == (iconv_t)-1) {
> 			zerr("cannot do charset conversion (iconv failed)");
> 			CHARSET_FAILED();
> 		    }
>
> Any idea if your iconv supports UCS-4BE?  GNU iconv will tell you with
> "iconv --list", but if you have a Solaris variant it's likely to be
> different.  Otherwise, could nl_langinfo(CODESET) not be returning
> anything?

In fact I am linking against libiconv from Blastwave.org at
/opt/csw/lib. However, the charset seems to be supported:

thor% /opt/csw/bin/iconv -l | grep UCS-4BE
UCS-4BE

The system trace looks like this:

16896:  sigprocmask(SIG_BLOCK, 0x080464E4, 0x080464C0)  = 0
16896:  sigprocmask(SIG_BLOCK, 0x080460B4, 0x08046090)  = 0
16896:  -> libiconv:libiconv_open(0xdf986e04, 0x80c1e90)

...and...

thor% mdb -p 16896
Loading modules: [ ]
 > 0xdf986e04/S
0xdf986e04:     646
 > 0x80c1e90/S
0x80c1e90:      UCS-4BE

Looks like there is no 646:

thor% /opt/csw/bin/iconv -l | grep 646
ANSI_X3.4-1968 ANSI_X3.4-1986 ASCII CP367 IBM367 ISO-IR-6 ISO646-US  
ISO_646.IRV:1991 US US-ASCII CSASCII
ISO-10646-UCS-2 UCS-2 CSUNICODE
ISO-10646-UCS-4 UCS-4 CSUCS4
ISO-IR-14 ISO646-JP JIS_C6220-1969-RO JP CSISO14JISC6220RO
CN GB_1988-80 ISO-IR-57 ISO646-CN CSISO57GB1988

Is this an error from zsh or is this a bug in libiconv?


Thanks!

   -- Dago

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

[Peter Stephenson]

Dagobert Michelsen wrote:
> 16896:  -> libiconv:libiconv_open(0xdf986e04, 0x80c1e90)
> 
> ...and...
> 
> thor% mdb -p 16896
> Loading modules: [ ]
>  > 0xdf986e04/S
> 0xdf986e04:     646
>  > 0x80c1e90/S
> 0x80c1e90:      UCS-4BE
> 
> Looks like there is no 646:
> 
> thor% /opt/csw/bin/iconv -l | grep 646
> ANSI_X3.4-1968 ANSI_X3.4-1986 ASCII CP367 IBM367 ISO-IR-6 ISO646-US  
> ISO_646.IRV:1991 US US-ASCII CSASCII
> ISO-10646-UCS-2 UCS-2 CSUNICODE
> ISO-10646-UCS-4 UCS-4 CSUCS4
> ISO-IR-14 ISO646-JP JIS_C6220-1969-RO JP CSISO14JISC6220RO
> CN GB_1988-80 ISO-IR-57 ISO646-CN CSISO57GB1988
> 
> Is this an error from zsh or is this a bug in libiconv?

The first argument comes directly from what nl_langinfo(CODESET) is
returning.  I've tried it on our rather old Solaris 8 system and I get
the same as you, 646---and my iconv doesn't handle that either.

I asked the nice man from Mountain View about "nl_langinfo CODESET 646"
and it seems Solaris just sort of does that if doesn't think much of the
current codeset (e.g. not installed).

So I think we just need to massage it to some reasonable default, which
probably means "US-ASCII" (I'm not sure why that's better than "ASCII",
which I thought was unique, but that's what people seem to use---POSIX
rather self-centredly suggests "POSIX" but iconv doesn't seem to support
that).  I don't think 646 means anything, so I haven't made this
dependent on system.  Assuming ASCII shouldn't be a problem:  if the
7-bit subset isn't ASCII the shell is likely to have disappeared in a
puff of smoke by now.

I suppose trapping "" is a good thing, too, since iconv_open() doesn't
appear to have useful defaults (and there's no reason why it should
have).

As they say in US police dramas, "I'm denying your 646".  Or something.

Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.177
diff -u -r1.177 utils.c
--- Src/utils.c	26 Feb 2008 14:50:05 -0000	1.177
+++ Src/utils.c	26 Feb 2008 16:02:07 -0000
@@ -4867,6 +4867,7 @@
 		} else {
 #   ifdef HAVE_ICONV
 		    ICONV_CONST char *inptr = inbuf;
+		    const char *codesetstr = nl_langinfo(CODESET);
     	    	    inbytes = 4;
 		    outbytes = 6;
 		    /* store value in big endian form */
@@ -4875,6 +4876,18 @@
 			wval >>= 8;
 		    }
 
+		    /*
+		     * 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.
+		     *
+		     * It shouldn't ever be NULL, but while we're
+		     * being paranoid...
+		     */
+		    if (!codessetstr || !*codsetstr ||
+			!strcmp(codesetstr, "646"))
+			codesetstr == "US-ASCII";
     	    	    cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");
 		    if (cd == (iconv_t)-1) {
 			zerr("cannot do charset conversion (iconv 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

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

[Oliver Kiddle]

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.

> +		    if (!codessetstr || !*codsetstr ||
> +			!strcmp(codesetstr, "646"))
> +			codesetstr == "US-ASCII";

Is the last line of this correct? Isn't it meant to be an assignment?

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.

Oliver

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

[Peter Stephenson]

On Tue, 26 Feb 2008 16:10:58 +0000
Peter Stephenson <pws@csr.com> wrote:
> +		    if (!codessetstr || !*codsetstr ||
> +			!strcmp(codesetstr, "646"))
> +			codesetstr == "US-ASCII";

Er, except that there are three mistakes in those three lines of code, as
Geoff pointed out.  I was lulled into a false sense of security because
this doesn't get compiled on my machine.  I tried it specially. 

Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.178
diff -u -r1.178 utils.c
--- Src/utils.c	26 Feb 2008 16:19:34 -0000	1.178
+++ Src/utils.c	26 Feb 2008 18:05:59 -0000
@@ -4885,9 +4885,9 @@
 		     * It shouldn't ever be NULL, but while we're
 		     * being paranoid...
 		     */
-		    if (!codessetstr || !*codsetstr ||
+		    if (!codesetstr || !*codesetstr ||
 			!strcmp(codesetstr, "646"))
-			codesetstr == "US-ASCII";
+			codesetstr = "US-ASCII";
     	    	    cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");
 		    if (cd == (iconv_t)-1) {
 			zerr("cannot do charset conversion (iconv 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

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

[İsmail Dönmez]

Hi,

On Tue, Feb 26, 2008 at 8:08 PM, Peter Stephenson <pws@csr.com> wrote:
> On Tue, 26 Feb 2008 16:10:58 +0000
>  Peter Stephenson <pws@csr.com> wrote:
>  > +                 if (!codessetstr || !*codsetstr ||
>  > +                     !strcmp(codesetstr, "646"))
>  > +                     codesetstr == "US-ASCII";
>
>  Er, except that there are three mistakes in those three lines of code, as
>  Geoff pointed out.  I was lulled into a false sense of security because
>  this doesn't get compiled on my machine.  I tried it specially.
>
>  Index: Src/utils.c
>  ===================================================================
>  RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
>  retrieving revision 1.178
>  diff -u -r1.178 utils.c
>  --- Src/utils.c 26 Feb 2008 16:19:34 -0000      1.178
>  +++ Src/utils.c 26 Feb 2008 18:05:59 -0000
>  @@ -4885,9 +4885,9 @@
>                      * It shouldn't ever be NULL, but while we're
>                      * being paranoid...
>                      */
>  -                   if (!codessetstr || !*codsetstr ||
>  +                   if (!codesetstr || !*codesetstr ||
>                         !strcmp(codesetstr, "646"))
>  -                       codesetstr == "US-ASCII";
>  +                       codesetstr = "US-ASCII";
>                     cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");
>                     if (cd == (iconv_t)-1) {
>                         zerr("cannot do charset conversion (iconv failed)");

Yeah my patch did the same. Thanks.

-- 
Never learn by your mistakes, if you do you may never dare to try again

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

[Dagobert Michelsen]

Hi Peter,

Am 26.02.2008 um 19:08 schrieb Peter Stephenson:
> Er, except that there are three

Four ;-)

> mistakes in those three lines of code, as
> Geoff pointed out.  I was lulled into a false sense of security  
> because
> this doesn't get compiled on my machine.  I tried it specially.
>
> Index: Src/utils.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
> retrieving revision 1.178
> diff -u -r1.178 utils.c
> --- Src/utils.c	26 Feb 2008 16:19:34 -0000	1.178
> +++ Src/utils.c	26 Feb 2008 18:05:59 -0000
> @@ -4885,9 +4885,9 @@
>  		     * It shouldn't ever be NULL, but while we're
>  		     * being paranoid...
>  		     */
> -		    if (!codessetstr || !*codsetstr ||
> +		    if (!codesetstr || !*codesetstr ||
>  			!strcmp(codesetstr, "646"))
> -			codesetstr == "US-ASCII";
> +			codesetstr = "US-ASCII";
>      	    	    cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE");

      	    	    cd = iconv_open(codesetstr, "UCS-4BE");

>  		    if (cd == (iconv_t)-1) {
>  			zerr("cannot do charset conversion (iconv failed)");

Do you have a clue about the other failing tests?


Best regards

   -- Dago

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

[Dagobert Michelsen]

Hi all,

Am 26.02.2008 um 20:19 schrieb Dagobert Michelsen:
> Do you have a clue about the other failing tests?

The testsuite now runs fine with my fix for the last fix
with the exception of one remaining failing test:

thor% ZTST_verbose=1 gmake TESTNUM=C02 check
if test -n "cc"; then \
           cd .. && DESTDIR= \
           gmake MODDIR=`pwd`/Test/Modules install.modules > /dev/ 
null; \
         fi
if ZTST_testlist="`for f in ./C02*.ztst; \
            do echo $f; done`" \
          ZTST_srcdir="." \
          ZTST_exe=../Src/zsh \
          ../Src/zsh +Z -f ./runtests.zsh; then \
          stat=0; \
         else \
          stat=1; \
         fi; \
         rm -rf Modules .zcompdump; \
         exit $stat
./C02cond.ztst: starting.
Running test: -a cond
Test successful.
Running test: -b cond
Test successful.
Running test: -c cond
Test successful.
Running test: -d cond
Test successful.
Running test: -e cond
Test successful.
Running test: -f cond
Test successful.
Running test: -g cond
Test successful.
Running test: -h cond
Test successful.
Running test: -k cond
Test successful.
Running test: -n cond
Test successful.
Running test: -o cond
Test successful.
Running test: -p cond
Test successful.
Running test: -r cond
Test successful.
Running test: -s cond
Test successful.
Running test: -u cond
Test successful.
Running test: -x cond
Test successful.
Running test: -z cond
Test successful.
Running test: -L cond
Test successful.
Running test: -O cond
Test successful.
Running test: -G cond
Test successful.
Running test: -N cond
Warning: not testing [[ -N file ]] (not supported with NFS)
Test successful.
Running test: -nt cond
Test ./C02cond.ztst failed: bad status 1, expected 0 from:
   [[ newnewnew -nt zerolength && ! (unmodified -nt zerolength) ]]
Was testing: -nt cond
./C02cond.ztst: test failed.
**************************************
0 successful test scripts, 1 failure, 0 skipped
**************************************
gmake: *** [check] Error 1


I suspect this part here from C02cond.ztst:

> # can't be bothered with -S
>
>   if [[ $OSTYPE == "cygwin" ]]; then
>     print -u$ZTST_fd "Warning: not testing [[ -N file ]] (not  
> supported on Cygwin)"
>     true
>   elif [[ "$(find . -prune -fstype nfs 2>/dev/null)" == "." ]]; then
>     print -u$ZTST_fd "Warning: not testing [[ -N file ]] (not  
> supported with NFS)"
>     true
>   else
>     print -u $ZTST_fd 'This test takes two seconds...'
>     sleep 2
>     cat unmodified
>     touch newnewnew
>     [[ -N newnewnew && ! -N unmodified ]]
>   fi
> 0:-N cond
> F:This test can fail on NFS-mounted filesystems as the access and
> F:modification times are not updated separately.  The test will fail
> F:on HFS+ (Apple Mac OS X default) filesystems because access times
> F:are not recorded.  Also, Linux ext3 filesystems may be mounted
> F:with the noatime option which does not update access times.
> F:Failures in these cases do not indicate a problem in the shell.
>
>   [[ newnewnew -nt zerolength && ! (unmodified -nt zerolength) ]]
> 0:-nt cond


If this is on NFS (which it is in my build environment) the
file 'newnewnew' is not generated and the following tests fail
instead of being skipped on NFS.


Best regards

   -- Dagobert

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

[Peter Stephenson]

Dagobert Michelsen wrote:
> If this is on NFS (which it is in my build environment) the
> file 'newnewnew' is not generated and the following tests fail
> instead of being skipped on NFS.

I can see how that might be problematic.  Here's the simple way out.

Index: Test/C02cond.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C02cond.ztst,v
retrieving revision 1.21
diff -u -r1.21 C02cond.ztst
--- Test/C02cond.ztst	10 Jan 2008 18:53:50 -0000	1.21
+++ Test/C02cond.ztst	26 Feb 2008 20:42:20 -0000
@@ -125,6 +125,10 @@
 
 # can't be bothered with -S
 
+  print -u $ZTST_fd 'This test takes two seconds...'
+  sleep 2
+  cat unmodified
+  touch newnewnew
   if [[ $OSTYPE == "cygwin" ]]; then
     print -u$ZTST_fd "Warning: not testing [[ -N file ]] (not supported on Cygwin)"
     true
@@ -132,10 +136,6 @@
     print -u$ZTST_fd "Warning: not testing [[ -N file ]] (not supported with NFS)"
     true
   else
-    print -u $ZTST_fd 'This test takes two seconds...'
-    sleep 2
-    cat unmodified
-    touch newnewnew
     [[ -N newnewnew && ! -N unmodified ]]
   fi
 0:-N cond



-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

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

[Peter Stephenson]

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

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

[Bart Schaefer]

On Feb 27, 11:29am, Peter Stephenson wrote:
}
} > 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.

It's beginning to sound as if it might be worthwhile making a configure
test for this.

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

[Oliver Kiddle]

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.

Oliver

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

[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?

-- 
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

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

[Dagobert Michelsen]

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

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

[Peter Stephenson]

Dagobert Michelsen wrote:
> > 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:

Thanks, I think that means that what we've got is OK, but as things
stand we could get away with something simpler; unless someone has a
killer argument for the simpler #ifdef test I'll leave it as it is.

-- 
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