Bootstrapping with OpenJDK 7
Hi, Is it possible to bootstrap the bsd port on OS X using the OpenJDK 7 binaries? I have followed the build instructions (as best I can) but I am using the OpenJDK 7 binaries instead of the Soylatte binaries. Steps I have done. 1. installed the OpenJDK binaries - put this in my path to ensure that it works 2. Upgraded to XCode 3.1 3. Installed the plugins (untarred) 4. unset my JAVA_HOME 5. Run the make command changing the ALT_BOOTDIR and ALT_BINARY_PLUGS_PATH I am running this on a Quad Core 64 bit OS X. I saw in the archive that the 64 bit build may not work. So, is this an issue that the build does not work on 64 OS X? Or that I cannot use the OpenJDK to bootstrap? BUILD FAILED /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:177: The following error occurred while executing this line: /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:414: The following error occurred while executing this line: /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:452: The following error occurred while executing this line: /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:501: Compile failed; see the compiler error output for details. the build/bsd-i586/langtools/build/ant-diagnostics.log does not have anything in it indicating an error. Michael
Yep, I got exactly the same thing using the OpenJDK 7 binaries. I haven¹t tried using the Soylatte binaries yet. gcc --version: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) OS 10.5.4 iMac with Core 2 Duo It appears to be javac that is complaining, but I also can¹t find any details about the problem in any of the output. -- Lachlan O'Dea CA Principal Software Engineer tel: +61 3 9944 6674 fax: +61 3 9944 6599 mobile: +61 412 390 650 odela01@ca.com "Facts are meaningless. You could use facts to prove anything that's even remotely true!" - Homer Simpson From: Michael Franz <mvfranz@gmail.com> Date: Sun, 7 Sep 2008 13:46:57 -0400 To: <bsd-port-dev@openjdk.java.net> Subject: Bootstrapping with OpenJDK 7 Hi, Is it possible to bootstrap the bsd port on OS X using the OpenJDK 7 binaries? I have followed the build instructions (as best I can) but I am using the OpenJDK 7 binaries instead of the Soylatte binaries. Steps I have done. 1. installed the OpenJDK binaries - put this in my path to ensure that it works 2. Upgraded to XCode 3.1 3. Installed the plugins (untarred) 4. unset my JAVA_HOME 5. Run the make command changing the ALT_BOOTDIR and ALT_BINARY_PLUGS_PATH I am running this on a Quad Core 64 bit OS X. I saw in the archive that the 64 bit build may not work. So, is this an issue that the build does not work on 64 OS X? Or that I cannot use the OpenJDK to bootstrap? BUILD FAILED /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:177: The following error occurred while executing this line: /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:414: The following error occurred while executing this line: /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:452: The following error occurred while executing this line: /Users/mfranz/developer/openjdk-bsd/bsd-port/langtools/make/build.xml:501: Compile failed; see the compiler error output for details. the build/bsd-i586/langtools/build/ant-diagnostics.log does not have anything in it indicating an error. Michael
Hi, It seems that I need to set both ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to get the build to run with the OpenJDK Darwin binaries. For people that did not have this problem, is there some other variable that is set that makes ALT_JDK_IMPORT_PATH unnecessary? Michael
My next problem is this: All done. cd bsd_i486_compiler2/product && ./test_gamma openjdk full version "1.7.0-internal-landonf_2008_08_20_14_13-b00" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-landonf_2008_08_20_14_13-b00) OpenJDK Server VM (build 14.0-b01, mixed mode) Exception in thread "main" java.lang.NoClassDefFoundError: Queens Caused by: java.lang.ClassNotFoundException: Queens at java.net.URLClassLoader$1.run(URLClassLoader.java:220) at java.net.URLClassLoader$1.run(URLClassLoader.java:209) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:208) at java.lang.ClassLoader.loadClass(ClassLoader.java:325) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:270) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:338) make[4]: *** [product] Error 1 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 I cannot find any reference to a 'Queens' class. Michael On Sun, Sep 21, 2008 at 4:57 PM, Michael Franz <mvfranz@gmail.com> wrote:
Hi,
It seems that I need to set both ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to get the build to run with the OpenJDK Darwin binaries.
For people that did not have this problem, is there some other variable that is set that makes ALT_JDK_IMPORT_PATH unnecessary?
Michael
Michael, Our bad (and our apologies). I don't know if there were legal issues with providing Queens.java or Queens.class or not. The end of the build tries to self-test. We should probably comment that out. You would need to have a java in your path to run any self-test anyway. What you have is a successful build of the hotspot vm. What you need to do is to copy the libjvm.dylib and libjsig.dylib into the location you are currently using to run your jre - whether that is a binary you downloaded, or a jdk you built. Of course you want to save the existing libjvm.dylib and libjsig.dylib. Make sure you copy over the server/libjvm.dylib if you built "product" - that is the optimizing, server compiler by default. hope this helps, Karen On Sep 21, 2008, at 5:54 PM, Michael Franz wrote:
My next problem is this: All done. cd bsd_i486_compiler2/product && ./test_gamma openjdk full version "1.7.0-internal-landonf_2008_08_20_14_13-b00" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal- landonf_2008_08_20_14_13-b00) OpenJDK Server VM (build 14.0-b01, mixed mode)
Exception in thread "main" java.lang.NoClassDefFoundError: Queens Caused by: java.lang.ClassNotFoundException: Queens at java.net.URLClassLoader$1.run(URLClassLoader.java:220) at java.net.URLClassLoader$1.run(URLClassLoader.java:209) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:208) at java.lang.ClassLoader.loadClass(ClassLoader.java:325) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:270) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:338) make[4]: *** [product] Error 1 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2
I cannot find any reference to a 'Queens' class.
Michael
On Sun, Sep 21, 2008 at 4:57 PM, Michael Franz <mvfranz@gmail.com> wrote: Hi,
It seems that I need to set both ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to get the build to run with the OpenJDK Darwin binaries.
For people that did not have this problem, is there some other variable that is set that makes ALT_JDK_IMPORT_PATH unnecessary?
Michael
Karen, I tried to copy the dyllibs, but that did not help. I looked at the IcedTea project and they remove the tests, so I did the same. I am now able to get past that point. What is in the Queens.java file? Is it an important test? Michael On Sun, Sep 21, 2008 at 9:03 PM, Karen Kinnear <Karen.Kinnear@sun.com>wrote:
Michael, Our bad (and our apologies). I don't know if there were legal issues with providing Queens.java or Queens.class or not. The end of the build tries to self-test. We should probably comment that out. You would need to have a java in your path to run any self-test anyway.
What you have is a successful build of the hotspot vm.
What you need to do is to copy the libjvm.dylib and libjsig.dylib into the location you are currently using to run your jre - whether that is a binary you downloaded, or a jdk you built. Of course you want to save the existing libjvm.dylib and libjsig.dylib. Make sure you copy over the server/libjvm.dylib if you built "product" - that is the optimizing, server compiler by default.
hope this helps, Karen
Michael, Let me be clearer. You have to copy the dylibs to test the new vm you built. You can test it by running any .class files you have, the Queens file is not important at all, it was just a very short .java file that made sure that the vm was warm and breathing. java -version would be a good check that you got your own build installed where you want it. thanks, Karen On Sep 21, 2008, at 10:33 PM, Michael Franz wrote:
Karen,
I tried to copy the dyllibs, but that did not help. I looked at the IcedTea project and they remove the tests, so I did the same. I am now able to get past that point.
What is in the Queens.java file? Is it an important test?
Michael
On Sun, Sep 21, 2008 at 9:03 PM, Karen Kinnear <Karen.Kinnear@sun.com> wrote: Michael,
Our bad (and our apologies). I don't know if there were legal issues with providing Queens.java or Queens.class or not. The end of the build tries to self-test. We should probably comment that out. You would need to have a java in your path to run any self-test anyway.
What you have is a successful build of the hotspot vm.
What you need to do is to copy the libjvm.dylib and libjsig.dylib into the location you are currently using to run your jre - whether that is a binary you downloaded, or a jdk you built. Of course you want to save the existing libjvm.dylib and libjsig.dylib. Make sure you copy over the server/libjvm.dylib if you built "product" - that is the optimizing, server compiler by default.
hope this helps, Karen
Karen, Thanks, that makes more sense. I think the build has almost finished, but there is an issue with strip. Seems that we are passing an unknown option '-g'. for f in `cat /Users/mfranz/developer/openjdk-bsd/bsd-port/build/bsd-i586/tmp/jdk-elf-files.list`; do \ chmod u+w ${f}; \ echo strip -g ${f}; \ strip -g ${f}; \ chmod go-w ${f}; \ done strip -g /Users/mfranz/developer/openjdk-bsd/bsd-port/build/bsd-i586/j2sdk-image/jre/lib/i386/client/libjvm.dylib strip: unrecognized option: -g Michael On Sun, Sep 21, 2008 at 10:36 PM, Karen Kinnear <Karen.Kinnear@sun.com>wrote:
Michael, Let me be clearer. You have to copy the dylibs to test the new vm you built.
You can test it by running any .class files you have, the Queens file is not important at all, it was just a very short .java file that made sure that the vm was warm and breathing. java -version would be a good check that you got your own build installed where you want it.
thanks, Karen
It seems that I was wrong on this. I do have a Queens.java file. The problem is that the JVM does not startup correctly to compile the class and then cannot find the class file when it tries to run the test. I cannot figure out why the JVM does not run correctly during the build. If I run the steps manually it works. What I don't understand is that it is pointing to the version I specify in the ALT_BOOT_DIR or ALT_JDK_IMPORT_PATH (I have them set the same) and not the version that I just built. Michael On Sun, Sep 21, 2008 at 5:54 PM, Michael Franz <mvfranz@gmail.com> wrote:
My next problem is this: All done. cd bsd_i486_compiler2/product && ./test_gamma openjdk full version "1.7.0-internal-landonf_2008_08_20_14_13-b00" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-landonf_2008_08_20_14_13-b00) OpenJDK Server VM (build 14.0-b01, mixed mode)
Exception in thread "main" java.lang.NoClassDefFoundError: Queens Caused by: java.lang.ClassNotFoundException: Queens at java.net.URLClassLoader$1.run(URLClassLoader.java:220) at java.net.URLClassLoader$1.run(URLClassLoader.java:209) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:208) at java.lang.ClassLoader.loadClass(ClassLoader.java:325) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:270) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:338) make[4]: *** [product] Error 1 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2
I cannot find any reference to a 'Queens' class.
Michael
On Sun, Sep 21, 2008 at 4:57 PM, Michael Franz <mvfranz@gmail.com> wrote:
Hi,
It seems that I need to set both ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to get the build to run with the OpenJDK Darwin binaries.
For people that did not have this problem, is there some other variable that is set that makes ALT_JDK_IMPORT_PATH unnecessary?
Michael
Hi, I created a clean install of OS X 10.5.5 and tried to build from the same directory I have working from a different boot drive. The build fails. With the same ant error message from before. In trying to figure out what I had changed before to fix this problem I realized that one step that I did not document was to create the ~/.ant/ant.conf file with ANT_ARGS=-diagnostics as the only value. I have no idea why this fixes the ant build problem. I tested with just having the file and that does not work. Is this some strange Ant bug? Something on OS X? Michael On Sun, Sep 21, 2008 at 4:57 PM, Michael Franz <mvfranz@gmail.com> wrote:
Hi,
It seems that I need to set both ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to get the build to run with the OpenJDK Darwin binaries.
For people that did not have this problem, is there some other variable that is set that makes ALT_JDK_IMPORT_PATH unnecessary?
Michael
participants (3)
-
Karen Kinnear
-
Michael Franz
-
odela01