We are in the process of evaluating build tool selections for JDK8.

For Windows, Anthony Petrov started the work and supplied a patch [1], plus more changes for hotspot.

I have successfully completed OpenJDK builds of the JDK8 build forest using Visual Studio 2012. The runtime .dll selection that Kelly is referring to takes place in toolchain_windows.m4.

The binaries produced by my builds passed a few basic checks like 'java -version' and ran the JVM98 benchmark for a few minutes. Much more testing remains to be done.

Here is a pointer to the source changes I needed to make, so far:

    http://cr.openjdk.java.net/~tbell/VS2012/webrev.00/

You will need to run 'bash common/autoconf/autoconf.sh' after applying the patch from the webrev.

It has also been reported that the free VS2012 'Express' edition does not include the 64-bit compiler, so you will be able to build 32-bit only. I have not verified that.

Tim

[1] http://hg.openjdk.java.net/jdk8/awt/rev/dd1a80efa7cf


On 05/22/13 04:27 PM, David Chase wrote:
I hope I'm trying to solve a simpler problem, which is just a build, as if I 
were someone outside Oracle playing with Openjdk.  I assume my problems are a 
subset of the release problem.

David

On 2013-05-22, at 6:53 PM, Kelly O'Hair <kellyoh...@gmail.com> wrote:

Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, 
which we must deliver with the JDK, so the build process has to know what that 
DLL is named, where it is located, and copy it into various places.

DLLs created by a newer VS will not like the older VS runtime DLLs.

To make a long story short, changing VS compilers is a royal pain, and not 
trivial.
This is why we only recommend VS2010.

I'm not saying it cannot be done, I'm just saying you should have plenty of 
liquor available when you do it. :^(

-kto

Reply via email to