Fix for 6888888 breaks the build
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
Fix for 6888888 breaks the build
by gnu_andrew
::
Rate this Message:
The fix for bug 6888888:
http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via JAVA_TOOLS_DIR) which is not set on normal builds. The README tells the user to set ALT_BOOTDIR and changing JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: http://cr.openjdk.java.net/~andrew/javah/webrev.01/ Ok to push? -- 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 |
|
|
Re: Fix for 6888888 breaks the build
by tim.bell
::
Rate this Message:
Andrew John Hughes wrote:
> The fix for bug 6888888: > > http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a > > breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via > JAVA_TOOLS_DIR) which is not set on normal builds. > The README tells the user to set ALT_BOOTDIR and changing > JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: Sorry about that - my mistake. As Andrew pointed out on IRC: you can work around the bug by setting ALT_JDK_IMPORT_DIR to the same as ALT_BOOTDIR Jon Gibbons has a fix to 6889255 out for review, which will remove the 6888888 workaround: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889255 http://cr.openjdk.java.net/~jjg/6889255-classreader.1 > http://cr.openjdk.java.net/~andrew/javah/webrev.01/ > > Ok to push? Unfortunately it is too late to fix in b74, and hopefully 6889255 will be fixed in b75. If not, I will come back to your patch. Tim |
|
|
Re: Fix for 6888888 breaks the build
by gnu_andrew
::
Rate this Message:
2009/10/15 Tim Bell <Tim.Bell@...>:
> Andrew John Hughes wrote: >> The fix for bug 6888888: >> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a >> >> breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via >> JAVA_TOOLS_DIR) which is not set on normal builds. >> The README tells the user to set ALT_BOOTDIR and changing >> JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: > > Sorry about that - my mistake. > > As Andrew pointed out on IRC: > > you can work around the bug by setting ALT_JDK_IMPORT_DIR to the same as ALT_BOOTDIR > > Jon Gibbons has a fix to 6889255 out for review, which will remove the 6888888 > workaround: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889255 > http://cr.openjdk.java.net/~jjg/6889255-classreader.1 > >> http://cr.openjdk.java.net/~andrew/javah/webrev.01/ >> >> Ok to push? > > Unfortunately it is too late to fix in b74, and hopefully 6889255 will be > fixed in b75. If not, I will come back to your patch. > > Tim > 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. -- 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 |
|
|
Re: Fix for 6888888 breaks the build
by jonathan.gibbons
::
Rate this Message:
2009/10/15 Tim Bell Tim.Bell@...: 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. -- Jon |
|
|
Re: Fix for 6888888 breaks the build
by tim.bell
::
Rate this Message:
> 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? Thanks- Tim |
|
|
Re: Fix for 6888888 breaks the build
by Kelly O'Hair
::
Rate this Message:
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 |
|
|
Re: Fix for 6888888 breaks the build
by gnu_andrew
::
Rate this Message:
2009/10/16 Kelly O'Hair <Kelly.Ohair@...>:
> > 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 |
|
|
Re: Fix for 6888888 breaks the build
by gnu_andrew
::
Rate this Message:
2009/10/26 Andrew John Hughes <gnu_andrew@...>:
> 2009/10/16 Kelly O'Hair <Kelly.Ohair@...>: >> >> 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 |
|
|
Re: Fix for 6888888 breaks the build
by jonathan.gibbons
::
Rate this Message:
Andrew John Hughes wrote:
Andrew,2009/10/26 Andrew John Hughes gnu_andrew@...:2009/10/16 Kelly O'Hair Kelly.Ohair@...: This should now be fixed. -- Jon |
|
|
Re: Fix for 6888888 breaks the build
by gnu_andrew
::
Rate this Message:
2009/10/26 Jonathan Gibbons <Jonathan.Gibbons@...>:
> Andrew John Hughes wrote: > > 2009/10/26 Andrew John Hughes <gnu_andrew@...>: > > > 2009/10/16 Kelly O'Hair <Kelly.Ohair@...>: > > > 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 |
|
|
Re: Fix for 6888888 breaks the build
by jonathan.gibbons
::
Rate this Message:
Andrew John Hughes wrote:
Andrew,2009/10/26 Jonathan Gibbons Jonathan.Gibbons@...:Andrew John Hughes wrote: 2009/10/26 Andrew John Hughes gnu_andrew@...: 2009/10/16 Kelly O'Hair Kelly.Ohair@...: 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. -- JonThat's excellent news. Do you happen to know which changeset(s) fix the issue? I can then pull them into IcedTea ahead of time. Here's the fix: Changeset: 2485f5641ed0 Author: jjg Date: 2009-10-19 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2485f5641ed0 6889255: javac MethodSymbol throws NPE if ClassReader does not read parameter names correctly Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6889255/T6889255.java |
| Free embeddable forum powered by Nabble | Forum Help |
