From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17316 invoked by alias); 20 Apr 2009 21:15:32 -0000 Received: (qmail 17121 invoked by uid 22791); 20 Apr 2009 21:15:28 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Apr 2009 21:15:19 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3KLEawl002245; Mon, 20 Apr 2009 17:14:36 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3KLEZmf013923; Mon, 20 Apr 2009 17:14:35 -0400 Received: from opsy.redhat.com (vpn-12-214.rdu.redhat.com [10.11.12.214]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3KLEYfV018902; Mon, 20 Apr 2009 17:14:34 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 7A8D637829A; Mon, 20 Apr 2009 15:14:33 -0600 (MDT) To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: prefer in-tree libiconv over the system libiconv? References: <20090420183619.GB5858@adacore.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Mon, 20 Apr 2009 21:36:00 -0000 In-Reply-To: <20090420183619.GB5858@adacore.com> (Joel Brobecker's message of "Mon\, 20 Apr 2009 11\:36\:19 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00158.txt.bz2 Joel> But, on the other hand, for a distributer like AdaCore (and maybe CS), Joel> it makes it harder to make sure which libiconv gets linked in. Joel> I suggest we change the logic a bit so that, if the libiconv sources Joel> are in-tree, then use this libiconv over the system one. The Joel> alternative is to have a configure switch that would allow us to Joel> specify the location of the libiconv install from the in-tree build. Joel> Thoughts? I think the relevant scenario is something like the old Cygnus "devo" tree, where you would have libiconv always present and also use the single soruce tree on all hosts. In this situation, would you prefer to pick up the system iconv on Linux? Or would you prefer to always use libiconv and have identical behavior across hosts (at some cost; I think the native glibc iconv probably handles more charsets). I guess specifying the libiconv prefix in the build tree might work. Something like --with-build-libiconv or --with-system-iconv would be simpler and less error-prone, though. Anyway, I'm happy to implement whatever approach you want here, just let me know. Tom