From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20996 invoked by alias); 20 Apr 2009 18:36:35 -0000 Received: (qmail 20988 invoked by uid 22791); 20 Apr 2009 18:36:34 -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; Mon, 20 Apr 2009 18:36:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5DAF82BAB58 for ; Mon, 20 Apr 2009 14:36:28 -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 f81SCCTVTC6H for ; Mon, 20 Apr 2009 14:36:28 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 28F2E2BAB4C for ; Mon, 20 Apr 2009 14:36:28 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 1BE21F58C9; Mon, 20 Apr 2009 11:36:19 -0700 (PDT) Date: Mon, 20 Apr 2009 20:32:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: prefer in-tree libiconv over the system libiconv? Message-ID: <20090420183619.GB5858@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00156.txt.bz2 Hello everyone, Tom and I were discussing about libiconv today: The idea is that, if you put the libiconv sources in the root directory of the GDB sources, configure will automatically pick it up and build GDB with this libiconv. However, the current setup is such that, if we find a system libiconv that provides the functionality we need, then the system libiconv is going to be used instead. This means that placing the libiconv sources in the GDB sources is not enough to make sure that GDB gets built with that libiconv. On the one hand, this is convenient if you just want GDB to be built without having to worry whether libiconv is available on the host or not. But, on the other hand, for a distributer like AdaCore (and maybe CS), it makes it harder to make sure which libiconv gets linked in. I suggest we change the logic a bit so that, if the libiconv sources are in-tree, then use this libiconv over the system one. The alternative is to have a configure switch that would allow us to specify the location of the libiconv install from the in-tree build. Thoughts? -- Joel