From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12395 invoked by alias); 6 May 2011 00:27:41 -0000 Received: (qmail 12378 invoked by uid 22791); 6 May 2011 00:27:40 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 May 2011 00:27:24 +0000 Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p460RMuh001297 for ; Thu, 5 May 2011 17:27:22 -0700 Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.18.118.116]) by kpbe13.cbf.corp.google.com with ESMTP id p460RLkm025900 for ; Thu, 5 May 2011 17:27:21 -0700 Received: by ruffy.mtv.corp.google.com (Postfix, from userid 67641) id DE3BF2461B1; Thu, 5 May 2011 17:27:20 -0700 (PDT) To: gdb-patches@sourceware.org Subject: [RFC] --with-iconv-path Message-Id: <20110506002720.DE3BF2461B1@ruffy.mtv.corp.google.com> Date: Fri, 06 May 2011 00:27:00 -0000 From: dje@google.com (Doug Evans) X-System-Of-Record: true X-IsSubscribed: yes 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/msg00169.txt.bz2 Hi. We have one environment where the iconv binary comes from a non-standard location. This patch lets one tell gdb where to find it. Before I write docs/NEWS, can anyone think of any problems with this approach? One alternative that I don't like is requiring the user to set $PATH to find the right iconv - that is an internal implementation detail the user shouldn't have to deal with. [Ideally one could query some iconv_*() function at runtime: It knows where its going to find its .so files, and iconv is typically at a fixed path relative to that. But I couldn't find such an interface. Another alternative would be to have an iconv_*() function that returned a list of all the charsets: that's all gdb uses the iconv program for. And I realize some environments have iconvlist. Alas one also has to work with the glibcs that are out there.] TIA 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. Index: charset.c =================================================================== RCS file: /cvs/src/src/gdb/charset.c,v retrieving revision 1.44 diff -u -p -r1.44 charset.c --- charset.c 21 Apr 2011 14:26:38 -0000 1.44 +++ charset.c 6 May 2011 00:14:37 -0000 @@ -799,6 +799,7 @@ find_charset_names (void) char *args[3]; int err, status; int fail = 1; + int flags; struct gdb_environ *iconv_env; /* Older iconvs, e.g. 2.2.2, don't omit the intro text if stdout is @@ -811,12 +812,20 @@ find_charset_names (void) child = pex_init (PEX_USE_PIPES, "iconv", NULL); +#ifdef ICONV_PATH + args[0] = ICONV_PATH; +#else args[0] = "iconv"; +#endif args[1] = "-l"; args[2] = NULL; + flags = PEX_STDERR_TO_STDOUT; +#ifndef ICONV_PATH + flags |= PEX_SEARCH; +#endif /* Note that we simply ignore errors here. */ - if (!pex_run_in_environment (child, PEX_SEARCH | PEX_STDERR_TO_STDOUT, - "iconv", args, environ_vector (iconv_env), + if (!pex_run_in_environment (child, flags, + args[0], args, environ_vector (iconv_env), NULL, NULL, &err)) { FILE *in = pex_read_output (child, 0); Index: configure.ac =================================================================== RCS file: /cvs/src/src/gdb/configure.ac,v retrieving revision 1.144 diff -u -p -r1.144 configure.ac --- configure.ac 17 Mar 2011 13:19:10 -0000 1.144 +++ configure.ac 6 May 2011 00:14:37 -0000 @@ -433,6 +433,16 @@ AC_SEARCH_LIBS(dlgetmodinfo, [dl xpdl]) AM_ICONV +# GDB may invoke iconv to get the list of supported character sets. +# Allow the user to specify where to find it. + +AC_ARG_WITH(iconv-path, +AS_HELP_STRING([--with-iconv-path=PATH], [specify where to find the iconv program]), +[iconv_path="${withval}" + AC_DEFINE_UNQUOTED([ICONV_PATH], ["${iconv_path}"], + [Path of iconv program.]) +]) + # On alpha-osf, it appears that libtermcap and libcurses are not compatible. # There is a very specific comment in /usr/include/curses.h explaining that # termcap routines built into libcurses must not be used.