From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26153 invoked by alias); 13 Mar 2009 23:25:40 -0000 Received: (qmail 26106 invoked by uid 22791); 13 Mar 2009 23:25:40 -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, 13 Mar 2009 23:25:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 89A842C9866; Fri, 13 Mar 2009 19:25:21 -0400 (EDT) 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 VGg85fbaU3me; Fri, 13 Mar 2009 19:25:21 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7E8482C982D; Fri, 13 Mar 2009 19:25:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 60A86F5C8D; Fri, 13 Mar 2009 16:25:15 -0700 (PDT) Date: Fri, 13 Mar 2009 23:37:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Thiago Jung Bauermann , Andre Oliveira Loureiro do Baixo , gdb-patches@sourceware.org Subject: Re: [PATCH] PR exp/9103 Message-ID: <20090313232515.GD30693@adacore.com> References: <20090311153711.GA5197@caradoc.them.org> <1236803010.11106.50.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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-03/txt/msg00221.txt.bz2 > * What to do about hosts without an iconv implementation. There are > three choices: > > 1. Require libiconv on such hosts > 2. Like #1, but provide a simple way to drop libiconv into the src > tree. > 3. Write a phony iconv-alike that only handles host charset == > target charset, probably also providing "gdb_wchar_t" and various > other macros and whatnot to make it all work. I am not completely opposed to (1). The problem with this option is that it complicates the requirements for building GDB. I remember that, not so long ago, I was keen on trying out the latest and greatest of various programs (Debian usually lags in the versions it ships, even with "testing". The problem was that the list of dependencies was so big that I never managed to build the program I was interested in within the amount of time that I allocated. GDB is quite far from being that bad, but I personally tend to be sensitive to these sort of issues. I'd like lambda people to be able to build GDB relatively simply without having to have to double-check that certain dependencies are met. That's why I usually tend to favor option (3), especially if it's not too much work to do. A slight variation of that option is what Daniel did for libexpat. Certain features are simply not present unless libexpat is available. Otherwise, we need to look at how portable GNU libiconv is. I don't expect any problem in that department, but then I was suprised to see that libexpat seemed to be broken on AIX for me. -- Joel