Fix for 6888888 breaks the build

Andrew John Hughes gnu_andrew at member.fsf.org
Mon Oct 26 21:12:40 UTC 2009 

2009/10/26 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
> Andrew John Hughes wrote:
>
> 2009/10/26 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>
>
> 2009/10/16 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
>
> Tim Bell wrote:
>
>
> Andrew John Hughes wrote:
>
>
> (snip!)
>
>
> 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.
>
>
>
> Jonathan Gibbons wrote:
>
>
>
> 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.
>
>
> 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?
>
>
> 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
>
>
>
> Thanks-
>
> Tim
>
>
> 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. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
>
>
> 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
> (http://java.sun.com/webapps/bugreport)  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.
>
>
> Andrew,
>
> This should now be fixed.
>
> -- Jon
>

That's excellent news.  Do you happen to know which changeset(s) fix
the issue?  I can then pull them into IcedTea ahead of time.
-- 
Andrew :-)

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

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the build-dev mailing list