Somewhat wonkier Windows problem

[David Chase]

Those changes look quite familiar, but more comprehensive.  Thanks.
I will give them a try in a minute, after I see how far I get with the 2010 DirectX SDK.

That one has the desirable property of not messing up %PATH%.
I suspect, based on others' experience, that we'll want need to adjust how we deal with DirectX if we want to use the not-2004 version (I didn't seen any occurrence of "directx" in your patch).

David

On 2013-05-22, at 8:44 PM, Tim Bell <tim.bell at oracle.com> wrote:

> 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 <kellyohair at 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