Fix for 6888888 breaks the build
Jonathan Gibbons
Jonathan.Gibbons at Sun.COM
Mon Oct 26 20:54:02 UTC 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20091026/f19065df/attachment.htm>
More information about the build-dev
mailing list