From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7298 invoked from network); 3 Mar 2008 12:45:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 3 Mar 2008 12:45:03 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 17787 invoked from network); 3 Mar 2008 12:44:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 3 Mar 2008 12:44:58 -0000 Received: (qmail 20500 invoked by alias); 3 Mar 2008 12:44:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24668 Received: (qmail 20482 invoked from network); 3 Mar 2008 12:44:55 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 3 Mar 2008 12:44:55 -0000 Received: from mail.blastwave.org (mail.blastwave.org [147.87.98.10]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1BA278028C52 for ; Mon, 3 Mar 2008 13:44:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.blastwave.org (Postfix) with ESMTP id 67A222E4F; Mon, 3 Mar 2008 13:44:07 +0100 (MET) X-Virus-Scanned: amavisd-new at blastwave.org Received: from mail.blastwave.org ([127.0.0.1]) by localhost (enterprise.blastwave.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A2i4sUt-TES3; Mon, 3 Mar 2008 13:43:39 +0100 (MET) Received: from [10.0.0.209] (253-202-103-86.dynamic.dsl.tng.de [86.103.202.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.blastwave.org (Postfix) with ESMTP id E6ED226A4; Mon, 3 Mar 2008 13:43:33 +0100 (MET) In-Reply-To: <20080303120851.0c25f94f@news01> References: <8AABEECB-A9A6-43EA-BED2-4BE376CBE349@blastwave.org> <20080226141459.76dc362c@news01> <20080226145741.6e74fc22@news01> <656429B3-438B-4ECF-85C4-04E38D837D1A@blastwave.org> <200802261610.m1QGAwJ3008939@news01.csr.com> <18951.1204047420@thecus> <200802271129.m1RBTVIC003639@news01.csr.com> <28293.1204278804@thecus> <20080303120851.0c25f94f@news01> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Zsh Hackers' List" Content-Transfer-Encoding: 7bit From: Dagobert Michelsen Subject: Re: * Re: Failed tests of zsh 4.3.5 in Solaris 10 w/Sun Studio 12 CC Date: Mon, 3 Mar 2008 13:43:22 +0100 To: Peter Stephenson X-Mailer: Apple Mail (2.753) X-Virus-Scanned: ClamAV 0.91.2/6092/Mon Mar 3 06:04:26 2008 on bifrost X-Virus-Status: Clean Hi, Am 03.03.2008 um 13:08 schrieb Peter Stephenson: > On Fri, 29 Feb 2008 10:53:24 +0100 > Oliver Kiddle 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 >> >> 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 > msg00003.html> Best regards -- Dagobert