From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48474 invoked by alias); 20 Aug 2015 15:47:17 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 48452 invoked by uid 89); 20 Aug 2015 15:47:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_20,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; Thu, 20 Aug 2015 15:47:15 +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 A25D68E753; Thu, 20 Aug 2015 15:47:14 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-201.phx2.redhat.com [10.3.113.201]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7KFlDkG013286; Thu, 20 Aug 2015 11:47:13 -0400 Subject: Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning To: Andrew Haley , Andrew Hughes References: <55CA44C8.7000209@redhat.com> <87mvxxdxys.fsf@tromey.com> <141970419.12686720.1440038099721.JavaMail.zimbra@redhat.com> <87y4h68tk3.fsf@tromey.com> <55D58ED0.1020402@ubuntu.com> <55D5909B.3080207@redhat.com> <401143105.13318272.1440082676204.JavaMail.zimbra@redhat.com> <55D5F1C8.7060003@redhat.com> Cc: Matthias Klose , Tom Tromey , Uros Bizjak , gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org From: Jeff Law Message-ID: <55D5F681.5060809@redhat.com> Date: Thu, 20 Aug 2015 15:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55D5F1C8.7060003@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-q3/txt/msg00027.txt.bz2 On 08/20/2015 09:27 AM, Andrew Haley wrote: > On 08/20/2015 03:57 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 20/08/15 09:24, Matthias Klose wrote: >>>> On 08/20/2015 06:36 AM, Tom Tromey wrote: >>>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of >>>>> Andrew> OpenJDK/IcedTea. >>>>> >>>>> Andrew Haley said the opposite here: >>>>> >>>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html >>>> >>>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj >>>> available for the target platform is required. Starting with OpenJDK >>>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8 >>>> available on the cross platform. It might be possible to cross >>>> build older OpenJDK versions, but this usually is painful. >>> >>> Sure, but we don't need GCJ going forward. I don't think that there >>> are any new platforms to which OpenJDK has not been ported which will >>> require GCJ to bootstrap. And even if there are, anybody who needs to >>> do that can (and, indeed, should) use an earlier version of GCJ. It's >>> not going to go away; it will always be in the GCC repos. And because >>> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more >>> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK. >> >> I don't see how we don't at present. How else do you solve the >> chicken-and-egg situation of needing a JDK to build a JDK? I don't >> see crossing your fingers and hoping there's a binary around >> somewhere as a very sustainable system. > > That's what we do with GCC, binutils, etc: we bootstrap. Right. So the question is there some reason why OpenJDK can't be used to bootstrap itself? Ie, is there a fundamental reason why Andrew needs to drop back down to GCJ and start the bootstrapping process from scratch. ISTM that ideally the previous version of OpenJDK would be used to bootstrap the new version of OpenJDK. Which leaves the question of how to deal with new platforms, but it sounds like there's a cross-compilation process starting with OpenJDK 8 which ought to solve that problem. > >> From a personal point of view, I need gcj to make sure each new >> IcedTea 1.x and 2.x release bootstraps. > > Sure, but all that does is test that the GCJ bootstrap still works. > And it's probably the only serious use of GCJ left. And how much value is there in that in the real world? > > It's not a sudden whim: it's something we've been discussing for years. > The only reason GCJ is still alive is that I committed to keep it > going while we still needed it boot bootstrap OpenJDK. Maintaining > GCJ in GCC is a significant cost, and GCJ has reached the end of its > natural life. Classpath is substantially unmaintained, and GCJ > doesn't support any recent versions of Java. Right. I think we last discuss this in 2013 and there was still some benefit in keeping GCJ building, but that benefit is dwindling over time. There's an ongoing cost to every GCC developer to keep GCJ functional as changes in the core compiler happen. Furthermore, there's a round-trip cost for every patch under development by every developer in the boostrap & testing cycles. Given the marginal benefit to GCC and OpenJDK and the fairly high cost, we'd really prefer to drop GCJ. Jeff