Fix for 6888888 breaks the build

Mon Oct 26 20:45:50 UTC 2009

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 :-)

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