Somewhat wonkier Windows problem

[David Chase]

VS2012, at least the one I downloaded recently, pretends to compile, and since ADLC ran, I think it produces images that run, too, so there is some hope.  It darn sure won't run if I don't get the build to complete.

Getting the DLLs right, I assume I'll drive off that bridge when I come to it.  That's all this is anyhow -- drive into a ditch, get out of the ditch, drive to the next ditch, lather, rinse, repeat.  We can't put this off forever, and speaking as someone who's used other open source stuff, it's really annoying when something I want to use declares that I need to install some 2-year-old down-rev stuff to make it work -- especially if I already have the new stuff installed and then get them confused -- for instance, accidentally picking up gcc 4.8 to build, instead of 4.2.

David

On 2013-05-22, at 7:54 PM, Kelly O'Hair <kellyohair at gmail.com> wrote:

> If you accept the fact that the build may complete but not work, then fine.
> But if you want the JDK you built to actually run, you will probably need to get the new msvcr*dll files placed in the jdk image area (in the bin dirs), manually or via the makefiles.
> 
> I also vaguely recall some silly thing with VS2012 that it was for Windows 8 only and you needed VS2012sp1 to be able to build for Windows releases before Windows 8?  I'm not sure I remember that right. :^(
> 
> -kto
> 
> On May 22, 2013, at 4: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
>> 
>