On May 7, 2013, at 1:59 AM, Volker Simonis wrote: > On Tue, May 7, 2013 at 3:10 AM, Pete Brunet <peter.bru...@oracle.com> wrote: > >> I tried changing my ALT_BOOTDIR from my normal 64 bit 7u21 installation >> to the 7u80 tarball I extracted, but got: >> make[2]: *** No rule to make target >> `../../../build/windows-i586/btjars/addjsum.jar', needed by >> `../../../build/windows-i586/lib/classlist'. Stop. >> >> FWIW, my ALT_JDK_IMPORT_PATH points at 7u80. >> >> > Using an IMPORT_JDK has become quite tricky and it seems that it only works > reliable if you use a build of the exact same version you are building as > import jdk.
That IS the way IMPORT_JDK is defined, it must be a recent JDK build, anything else can be unreliable. Any flag day changes (like jdk<->vm interface changes) will mess you up. I thought that was well documented somewhere. -kto > > Just yesterday I had a similar problem with JDK8 where I used a 4 weeks old > import jdk to build a brand new version of the 'jdk' forest. It failed > because during the build the VM from the import JDK is used together with > the newly build jdk classes but there was a mismatch in the unsafe > primitives requested by the Unsafe class and those provided by the VM. > > So the interface between the HotSpot VM and the class library has become > quite volatile (and it is still not documented anywhere:( > > >> I changed my ALT_BOOTDIR back to 7u21 and did a full build, not just >> jdk, and after a three hour build time all is well. >> >> Pete >> >> On 5/6/13 3:38 AM, Volker Simonis wrote: >>> What does "../../../../build/windows-i586/bin/java -version" return? >>> That must be HotSpot 24 (i.e. something like '..build 24.0-b34..'). >>> >>> How did you specify your boot-jdk? Maybe you didn't really build a new >>> hotspot but imported it from the boot-jdk and that was too old? >>> >>> If you want you can compare your build logs with our nightly build >>> logs of jdk7u on windows >>> at: >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz >>> >>> Regards >>> Volker >>> >>> >>> On Sat, May 4, 2013 at 5:40 AM, John Rose <john.r.r...@oracle.com> >> wrote: >>>> On May 3, 2013, at 8:42 AM, Pete Brunet <peter.bru...@oracle.com> >> wrote: >>>> >>>>> Error occurred during initialization of VM >>>>> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle >>>> It's a micro-version mismatch, from running a down-rev JVM on an up-rev >> rt.jar (JDK). >>>> >>>> But I don't understand why your makefile is running an old JVM on a new >> rt.jar. That's build voodoo, I presume. >>>> >>>> — John >> >>
