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. 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 > >
