From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51819 invoked by alias); 27 Oct 2016 16:00:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 51764 invoked by uid 89); 27 Oct 2016 16:00:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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 ESMTP; Thu, 27 Oct 2016 15:59:52 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 98B43BB1B; Thu, 27 Oct 2016 15:59:50 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-52.phx2.redhat.com [10.3.116.52]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9RFxmJh003715; Thu, 27 Oct 2016 11:59:49 -0400 Subject: Re: [PATCH] Fix bootstrap with --enable-languages=all,go To: Rainer Orth References: <78f841e7-808b-58d0-7913-3ec0d19630a0@redhat.com> <84c4f4e2-3048-f5f8-de72-b2f704aa1389@redhat.com> <20160930102746.GB3223@redhat.com> <20160930185531.GE7282@tucnak.redhat.com> <20161004092321.GH7282@tucnak.redhat.com> Cc: Jakub Jelinek , Eric Gallager , Andrew Haley , Ian Lance Taylor , Marek Polacek , gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: Date: Thu, 27 Oct 2016 16:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg02285.txt.bz2 On 10/27/2016 05:00 AM, Rainer Orth wrote: > Hi Jeff, > >> On 10/19/2016 06:13 AM, Rainer Orth wrote: >>> Hi Jakub, >>> >>>>> 2016-10-01 Rainer Orth >>>>> >>>>> * configure.ac (target_libraries): Readd target-boehm-gc. >>>>> Restore --enable-objc-gc handling. >>>>> * configure: Regenerate. >>>> >>>> This is incomplete. I guess it can be committed as is, but should be >>>> followed by re-addition of: >>>> bfin-*-*) >>>> noconfigdirs="$noconfigdirs target-boehm-gc" >>>> ;; >>>> cris-*-* | crisv32-*-*) >>>> case "${target}" in >>>> *-*-linux*) >>>> ;; >>>> *) # See PR46792 regarding target-libffi. >>>> noconfigdirs="$noconfigdirs target-boehm-gc";; >>>> esac >>>> ;; >>>> mmix-*-*) >>>> noconfigdirs="$noconfigdirs target-boehm-gc" >>>> ;; >>>> (perhaps in the same case as target-libffi handling). >>> >>> sorry I missed this. I can still re-add it if desired, but would rather >>> keep it in a separate case from the target-libffi handling: in-tree >>> boehm-gc may be replaced with an external version, while libffi is >>> likely to stay for libgo. >> I think disabling of target-boehm-gc for these targets was because they >> didn't support Java for various reasons. However, ISTM that we'd need it > > but wouldn't it have been sufficient to just disable libjava in this > case? boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC. It would have been sufficient -- I think it was just overlooked as an option at the time. > >> In theory we could build those targets after configuring with >> --eanble-objc-gc as a test. > > True, but that would need complete cross-development environments for > those targets. I'm certainly not up for that, especially not at this > point. :-) It was just an observation, certainly not going to require that of you. jeff