Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Jeff Law <law@redhat.com>]

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