From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21632 invoked by alias); 13 Mar 2009 23:37:57 -0000 Received: (qmail 21624 invoked by uid 22791); 13 Mar 2009 23:37:57 -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:37:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 852FB2C98BC; Fri, 13 Mar 2009 19:37: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 C-OSsLtlSoYZ; Fri, 13 Mar 2009 19:37:21 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6B88C2C98B8; Fri, 13 Mar 2009 19:37:19 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id F1284F5C8D; Fri, 13 Mar 2009 16:37:12 -0700 (PDT) Date: Fri, 13 Mar 2009 23:38: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: <20090313233712.GE30693@adacore.com> References: <20090311153711.GA5197@caradoc.them.org> <1236803010.11106.50.camel@localhost.localdomain> <20090313232515.GD30693@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090313232515.GD30693@adacore.com> 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/msg00222.txt.bz2 > I am not completely opposed to (1). > The problem with this option is [...] Humpf. I have a short memory. I see that we've discussed this before. I was checking out the message you wanted some feedback on, and that's when I noticed that we've touched on this subject. I see that option (3) doesn't work very well for you, which is unfortunate. I don't know iconv all that well, but from the web page, it seems like it's just a few functions. Can we provide a trivial implementation that just does nothing, as if the charsets were identical? If that doesn't work, then I'm ok with adding this to the list of build dependencies, since we have --with-libiconv-prefix (I assume that this will allow us to build GDB with a static version of libiconv if the path points to a static-only install). -- Joel