From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30192 invoked by alias); 3 Feb 2009 00:41:56 -0000 Received: (qmail 30182 invoked by uid 22791); 3 Feb 2009 00:41:55 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Feb 2009 00:41:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id BD7882A9664; Mon, 2 Feb 2009 19:41:50 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PIPbJGgujxmS; Mon, 2 Feb 2009 19:41:50 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7DA4B2A965D; Mon, 2 Feb 2009 19:41:50 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 47B29E7ACD; Mon, 2 Feb 2009 16:41:48 -0800 (PST) Date: Tue, 03 Feb 2009 00:41:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Julian Brown , gdb-patches@sourceware.org Subject: Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support Message-ID: <20090203004148.GC3964@adacore.com> References: <20090115202411.5f154657@rex.config> <20090130194343.GA3964@adacore.com> <20090201182344.GD4597@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00044.txt.bz2 > How are you planning to handle this for Code Sourcery? Really I would > like to hear the answer to this from anybody shipping a gdb > executable. As far as AdaCore is concerned, I think it will be fine to link GDB with a static libiconv. I didn't realize that we already had a --with-libiconv-prefix configure switch. It would have been nice to be able to build without, but if it's going to be painful or complexify the code, then maybe the gain is too small for it to be worth it. I don't know GNU libiconv well enough to know how portable it is. Maybe it's going to be a lot of "fun" building it on OSes such as LynxOS, but for now, LynxOS is not a supported host (I don't think), so we can worry about this problem later. (I'm also taking a look at the source right now) -- Joel