<!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:17c6771e0910261345r531fd54eg1cafa401e71116fa@mail.gmail.com"
type="cite">
<pre wrap="">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>:
</pre>
<blockquote type="cite">
<pre wrap="">2009/10/16 Kelly O'Hair <a class="moz-txt-link-rfc2396E" href="mailto:Kelly.Ohair@sun.com"><Kelly.Ohair@sun.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Tim Bell wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Andrew John Hughes wrote:
</pre>
</blockquote>
<pre wrap="">(snip!)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I think there's still an issue here that makes this patch worth
pushing. The 6888888 fix didn't cause the bug, but merely made it
visible to a lot more people. So 6889255 will only hide it again.
The build uses JAVA_TOOLS_DIR for javac, javah and javadoc:
# If no explicit tools, use boot tools (add VM flags in this case)
JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \
$(JAVACFLAGS)
JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \
$(JAVAHFLAGS)
JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%)
but only when LANGTOOLS_DIST is not defined. Normally, langtools is
built first so LANGTOOLS_DIST is defined. What your fix for 6888888
did was cause the setting for JAVAH to get used in all cases and, as
JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR
this fails in many cases as the user sets ALT_BOOTDIR not
ALT_JDK_IMPORT_PATH.
In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to
${jdk_instances}/${importjdk} if it exists. On Solaris,
${jdk_instances} is set to /usr/jdk/instances which probably explains
why Sun engineers building on Solaris may not see this bug either.
${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros
tend to have standardised on /usr/lib/jvm. It's simply "C:" on
Windows. As mentioned on IRC, release engineering are setting
ALT_JDK_IMPORT_PATH explicitly so also would never see this bug.
As we presumably want the tools from the bootstrap JDK, and not from
'the import JDK to be used to get hotspot VM if not built', I suggest
we switch to BOOTDIR by default by applying this patch.
</pre>
</blockquote>
</blockquote>
<pre wrap="">Jonathan Gibbons wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This probably explains problems I've reported informally to Kelly a
while back, but never got around to formally investigating. FWIW,
this fix does not interfere with the fix for 6889255 coming up, and this
fix seems like a good idea to me.
</pre>
</blockquote>
<pre wrap="">OK - I filed a new bug report:
6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR"
with a pointer to this email thread.
Kelly - do you have an opinion on this?
</pre>
</blockquote>
<pre wrap="">The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH
at all. And all class files would have been created by the LANGTOOLS_DIST
compiler (hotspot was a special case, using the ALT_BOOTDIR to compile).
But no class files would ever be created by the javac in ALT_BOOTDIR.
ALT_JDK_IMPORT_PATH was supposed to only come into play when someone
was doing what I called a 'partial build', and it provided the missing
pieces, including a jdk7 flavored javac compiler.
The other tools were less well defined in their use.
The jar tool in ALT_BOOTDIR is always used to build jars as I recall.
The javah and javadoc story I'm not so sure about. I thought they would
have followed the same rules as javac.
Not sure my ramblings are helping here.... :^(
-kto
</pre>
<blockquote type="cite">
<pre wrap="">Thanks-
Tim
</pre>
</blockquote>
</blockquote>
<pre wrap="">Did we come to a decision on this? I was reminded of it today because
none of the forests will build for me (except IcedTea which I've
patched) due to this bug.
If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at
least make it default to the BOOTDIR rather than a deliberately broken
path. Though I still fail to see the need to point to two different
JDKs simultaneously...
--
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
</pre>
</blockquote>
<pre wrap=""><!---->
I take it this is the error:
# Running javah:
/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah -bootclasspath
/mnt/builder/icedtea7/openjdk/build/linux-amd64/classes -d
/mnt/builder/icedtea7/openjdk/build/linux-amd64/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/
\
sun.security.pkcs11.wrapper.PKCS11 sun.security.pkcs11.Secmod
An exception has occurred in the compiler (1.7.0_0). Please file a bug
at the Java Developer Connection
(<a class="moz-txt-link-freetext" href="http://java.sun.com/webapps/bugreport">http://java.sun.com/webapps/bugreport</a>) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
java.lang.NullPointerException
at com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1226)
at com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1252)
at com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1)
at javax.lang.model.util.ElementScanner6.visitExecutable(ElementScanner6.java:191)
at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1260)
at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1)
at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129)
at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169)
at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874)
at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1)
at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129)
at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169)
at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874)
at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:825)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1070)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806)
at com.sun.tools.javac.main.Main.compile(Main.java:400)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:139)
at com.sun.tools.javah.JavahTask.run(JavahTask.java:482)
at com.sun.tools.javah.JavahTask.run(JavahTask.java:319)
at com.sun.tools.javah.Main.main(Main.java:46)
Should have clicked with me earlier, but I presume this also stops a
full bootstrap as well as the FontManager issue
(/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah above is the
just-built OpenJDK). Looks like IcedTea won't be able to support b74.
I hope RE learn from this and do a full bootstrap before promoting
b75, especially as that one is supposed to be the milestone. b74
certainly gets the award for most broken promoted build so far.
</pre>
</blockquote>
Andrew,<br>
<br>
This should now be fixed.<br>
<br>
-- Jon<br>
</body>
</html>