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

[Andrew Hughes <gnu.andrew@redhat.com>]

----- Original Message -----
> On 08/20/2015 10:03 AM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> 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.
> >>
> >
> > The issue is that we're still supporting a version of OpenJDK/IcedTea where
> > there is no previous version (6). Once that goes, gcj could go too. This
> > is still just a little too soon.
> But surely OpenJDK6 can build OpenJDK6, right?  I don't see you're
> fundamentally getting anything from always starting with a GCJ bootstrap.
> 

I'm talking about when you don't already have OpenJDK 6.

> >
> > That's where it comes unstuck. How do you get a JDK built when there are
> > no JDK binaries for your architecture?
> Cross compilation, just like folks do for Ada.
> 

Which still needs a JDK somewhere and, as Matthias mentioned, the build
system on older versions of OpenJDK (the ones were talking about) doesn't
really support cross-compilation. I had to hack around just to get x86 on
x86_64 to work.

> 
> >>
> >
> > I'm not against this long-term, just not immediately. Deprecating it now
> > and removing it in the next release cycle (7?) would probably be enough,
> > but we need a little more time to wind down dependencies. I don't see us
> > needing it in a GCC released in 2017.
> I was of the opinion that we should remove it from the default languages
> to be built.  Others wanted to be more aggressive :-)

I actually thought that change would have happened a long long time ago ;)

I'm actually for the aggressive approach, just on a longer time scale, as
I'll need time to transition IcedTea away from gcj.

> 
> jeff
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07