From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23001 invoked by alias); 22 Aug 2015 17:05:04 -0000 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 Received: (qmail 22968 invoked by uid 89); 22 Aug 2015 17:05:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 22 Aug 2015 17:05:03 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id BF9E58CF76; Sat, 22 Aug 2015 17:05:01 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7MH4wnd028173; Sat, 22 Aug 2015 13:04:59 -0400 Message-ID: <55D8ABBA.3090208@redhat.com> Date: Sat, 22 Aug 2015 17:05:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yaakov Selkowitz , gcc-patches@gcc.gnu.org, "binutils@sourceware.org" , "gdb-patches@sourceware.org" Subject: Re: [PATCH] config: fix AM_ICONV for in-tree libiconv References: <1432934749.13692.9.camel@redhat.com> In-Reply-To: <1432934749.13692.9.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00635.txt.bz2 On 05/29/2015 10:25 PM, Yaakov Selkowitz wrote: > This is the second in a series of patches to make a build with an > in-tree GNU libiconv work as designed. > > Currently GDB is the only toolchain component which actually uses an > in-tree libiconv. This patch modifies the common AM_ICONV to use an > in-tree libiconv when present and not already provided by libc. (GDB's > workaround uses an in-tree libiconv even when libc provides iconv(3); > I'm not sure when or why that would be desirable.) > > Once these two patches are merged in to each tree, I will follow with > patches to regenerate the various configure scripts and a few other > minor corresponding changes. I noticed that regenerating binutils/configure or gdb/configure undoes the libiconv changes done here: commit 016a3251631341bf4d8fe50966d2b70f8ea69e96 Author: DJ Delorie AuthorDate: Thu Aug 6 18:35:26 2015 -0400 Commit: DJ Delorie CommitDate: Thu Aug 6 23:55:06 2015 -0400 Yaakov Selkowitz: fixes for in-tree libiconv * Makefile.def (libiconv): Define bootstrap=true. Mark pdf/html/info as missing. (configure-gcc): Depend on all-libiconv. (all-gcc): Ditto. (configure-libcpp): Ditto. (all-libcpp): Ditto. (configure-intl): Ditto. (all-intl): Ditto. * Makefile.in: Regenerate. binutils/ * configure: Regenerate. gdb/ * Makefile.in (LIBICONV): Define. (CLIBS): Add LIBICONV. * acinclude.m4: Use config/iconv.m4 instead of custom AM_ICONV. * configure: Regenerate. However, that commit does not include any config/iconv.m4/AM_ICONV change. Looks like you forgot to attach the config/iconv.m4 patch, and then only the regeneration bits were pushed (both binutils-gdb git and gcc svn)? Thanks, Pedro Alves