From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29438 invoked by alias); 30 Jan 2009 19:43:54 -0000 Received: (qmail 29429 invoked by uid 22791); 30 Jan 2009 19:43:53 -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; Fri, 30 Jan 2009 19:43:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8D6382A96C6; Fri, 30 Jan 2009 14:43:47 -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 4JOMYi6xMxJX; Fri, 30 Jan 2009 14:43:47 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 34CC32A96C2; Fri, 30 Jan 2009 14:43:45 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 35584E7ACD; Fri, 30 Jan 2009 11:43:43 -0800 (PST) Date: Fri, 30 Jan 2009 22:14: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: <20090130194343.GA3964@adacore.com> References: <20090115202411.5f154657@rex.config> 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-01/txt/msg00544.txt.bz2 Hi Tom, I'm not very familiar with character encodings, so I won't review the patch. However, something caught my attention: > * With this patch, GDB requires iconv. I don't think it is a good use > of our time to implement and maintain our own character set > conversion library. I removed all the old code in charset.c that > attempted this. External dependencies of this sort can be a real issue. It's probably not very hard as you mention to build it on our machines, but that still leaves the problem of distribution. In other words, when we distribute a GDB binary to one of our customers, we pretty much need to distribute the iconv library as well. Do you think we could have a configure option that allows us to deactivate this feature in order to avoid the dependency? The other alternative is to have a configure option that allows us to specify where to look for the iconv library and headers. At our level, we would then link GDB against the static libiconv. It makes the GDB exe bigger but that's in exchange for an extra feature... In fact, both options are actually independent and have merits on their own, but either of them would be sufficient to help avoiding a dynamic dependency on a shared library... -- Joel