<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew John Hughes wrote:
<blockquote
cite="mid:17c6771e0910261818l434a940ax8ae16bc4c5f0e3e5@mail.gmail.com"
type="cite">
<pre wrap="">2009/10/26 Jonathan Gibbons <a class="moz-txt-link-rfc2396E" href="mailto:Jonathan.Gibbons@sun.com"><Jonathan.Gibbons@sun.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Andrew John Hughes wrote:
2009/10/26 Andrew John Hughes <a class="moz-txt-link-rfc2396E" href="mailto:gnu_andrew@member.fsf.org"><gnu_andrew@member.fsf.org></a>:
2009/10/26 Kelly O'Hair <a class="moz-txt-link-rfc2396E" href="mailto:Kelly.Ohair@sun.com"><Kelly.Ohair@sun.com></a>:
FYI...
-------- Original Message --------
Subject: Boot cycle builds
Date: Mon, 26 Oct 2009 11:21:22 -0700
From: Kelly O'Hair <a class="moz-txt-link-rfc2396E" href="mailto:Kelly.Ohair@Sun.COM"><Kelly.Ohair@Sun.COM></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:jdk7-gk@openjdk.java.net">jdk7-gk@openjdk.java.net</a>
Heads up...
As soon as we can do a jdk7 boot cycle build again, I plan on changing
the default build to include a boot cycle build
(where the jdk7 image is built, then used as the boot jdk to build
it again).
I consider it critical that boot cycle builds work, and I see
no other course than requiring it as part of a default jdk7 build.
It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the
integrators and everyone will be careful when it is turned off.
Depending on your build situation, this could add 20-30 minutes
(maybe more) to your jdk7 build, which is painful I know, but
so is finding out that the jdk you just built doesn't work.
Comments are welcome.
-kto
IcedTea does just this for a full bootstrap (the default) and it would
be good to see the Sun developers applying the same level of testing
to their builds.
I would ask that we wait until the end of the current milestone (this
week I believe) before adding this though.
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (<a class="moz-txt-link-freetext" href="http://www.redhat.com">http://www.redhat.com</a>)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
<a class="moz-txt-link-freetext" href="http://www.gnu.org/software/classpath">http://www.gnu.org/software/classpath</a>
<a class="moz-txt-link-freetext" href="http://openjdk.java.net">http://openjdk.java.net</a>
PGP Key: 94EFD9D8 (<a class="moz-txt-link-freetext" href="http://subkeys.pgp.net">http://subkeys.pgp.net</a>)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
To add to that, I think just having RE doing a full bootstrap would
have prevented the issues we've just hit with b74 (for the
uninitiated, changes to both javah and sun.awt.FontManager broke the
build).
Andrew,
The full bootstrap would not have uncovered the issues with the changes to
javah. I did full bootstrap builds. The issue arose with fastdebug builds.
-- Jon
</pre>
</blockquote>
<pre wrap=""><!---->
Strange; I did see the error when bootstrapping via IcedTea.
</pre>
</blockquote>
Andrew,<br>
<br>
The fault shows up if you use the javac -g option. That is not the case
in normal JDK builds, with or without the bootstrap build.<br>
<br>
-- Jon<br>
</body>
</html>