From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20918 invoked by alias); 6 May 2011 15:12:31 -0000 Received: (qmail 20908 invoked by uid 22791); 6 May 2011 15:12:30 -0000 X-SWARE-Spam-Status: No, hits=-2.0 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, 06 May 2011 15:12:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id BD6622BB2FD; Fri, 6 May 2011 11:12:15 -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 bCxB59-bJ6KM; Fri, 6 May 2011 11:12:15 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 907C22BB2FC; Fri, 6 May 2011 11:12:15 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 536BF145615; Fri, 6 May 2011 08:12:12 -0700 (PDT) Date: Fri, 06 May 2011 15:12:00 -0000 From: Joel Brobecker To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFC] --with-iconv-path Message-ID: <20110506151212.GA19356@adacore.com> References: <20110506002720.DE3BF2461B1@ruffy.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110506002720.DE3BF2461B1@ruffy.mtv.corp.google.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-05/txt/msg00189.txt.bz2 > We have one environment where the iconv binary comes from a > non-standard location. This patch lets one tell gdb where to find it. Does it mean that the libiconv libraries are at one location, and that the binary is at a different location? Looking at your patch, it looks like you might have a situation where the name of the iconv binary itself is different... > 2011-05-05 Doug Evans > > * configure.ac: New configure option --with-iconv-path. > * configure: Regenerate. > * config.in: Regenerate. > * charset.c (find_charset_names): Use ICONV_PATH if defined. "path" had me confused, and made me think that you were going to pass the name of the directory where iconv is located. But the patch seems to be contradicting that. If we don't need to specify the name of the iconv directory, then perhaps we could just focus on the directory name itself. We could even make that directory name relatocatable, the same way we make some of the paths relocatable as well. Normally, we have sets of switches that look like this: --with-xxx=PATH --with-xxx-lib=PATH --with-xxx-include=PATH etc We already have --with-libiconv-prefix. So, how about naming it --with-libiconv-bin ? If we think that it would be convenient to specify the iconv exe as well, how about --with-libiconv-exe or --with-libiconv-program? -- Joel