Errors in windows build?

[Kelly O'Hair]

Changing C/C++ compilers should be an easy thing to do, but it is not.

Even if you get it so that it "builds", that doesn't mean much.
The Hotspot VM is also a compiler, and generates native code, and that code will
connect to or get run with the C/C++ generated code at some point.
Minor tweaks to the C/C++ optimized code can collide with optimizations
done in the Hotspot generated code sometimes, register usage assumptions etc.
Sometimes it's our fault, sometimes it's poor specs, sometimes it's bugs
in the C/C++ compiler and we have to disable optimizations on certain source files.
Some of these nastier problems take Hotspot VM experts to track down.
And even after you think it runs correctly, there is the performance
benchmarks we have to check to verify we haven't regressed.
It has gotten easier over the years, but it is still a trip through
a potential mine field. Don't get me wrong, we need to upgrade compilers,
and the free ones are ideal, and I've usually the one trying to get us
moved to new compilers, but it's never fun to track down compiler errors,
no matter whose they are.

It's easy for any project to under-estimate changes to the build system.

In the past, the Visual Studio (VS) compilers changed so much from release to
release that it wasn't simple to transition to a new version, sometimes
even a service pack could break things (this was true in VC6).
Some of this was due to the C++ compiler conforming to the C++ standard,
but some of it was the habit of the VS compilers to remove options,
change options, or change the meaning of optimization options.
I think things have stabilized around the C++ standard, all the platform
compilers shared this issue to some degree.

The Platform SDK compiler seems to be potluck, and if it does have a 32bit
compiler in it, I kind of doubt it's complete, but I could be wrong.
The current April 2005 Platform SDK we use on 64bit Windows behaves a little
like a VS2005 product but isn't, so it's some kind of early VS2005 compiler
as best as I can tell. We should change to the March 2006 version I suppose,
but it took us many weeks to track down the problems that this April 2005
one forced out of the product.

Years ago when we investigated the VS2003 free compiler, it was missing some
key LIB files that we needed to build part of the jdk, LIB files only available
with the purchased product. So we abandoned that effort. The VS2005 free version
may be different, but I did hear that it didn't play well with the latest
Platform SDK on 32bit Windows (you have to change something to get them to
play together?).
Keep in mind that we currently still build on and support Windows 2000, and
ever time we upgrade compilers we have to make sure our overall support platform
story still works.
As we visit the list of official supported build and runtime platforms for JDK7,
I'm not sure if Windows 2000 stays in the picture or not. Remains to be seen.

 From a developer point of view, I'd like to say "use what you want", but when
it comes down to official builds, and which of the numerous combinations of
OS, compilers, SDK's, etc. we can test build on, there are limitations.
We need stability in our build systems to create stable products, so we
can be downright paranoid when changing any official build components.
Developers should have more flexibility, and can take more risks.

We thought about picking some "common developer" configurations and maybe
put some automated OpenJDK build/testing around those, maybe:

   * Solaris Express & Sun Studio 12 compilers
   * Linux Ubuntu & gcc 4
   * Windows XP and VS2005 free compiler

But we just aren't there yet, and Windows is low on the priority list.

I hope this helps explain things, sorry about the long winded answer.

-kto

Ted Neward wrote:
> True, but as Dan points out, just knowing that "somebody" (even if it's just
> one person) can build it helps build confidence immeasurably.
> 
> Meanwhile, has anyone tried to build it with just the Platform SDK? If I'm
> not mistaken (which I could be), I think there's a C++ compiler that comes
> with it. If nothing else, it plus the VC++ Express install should be
> everything that VC++ has in 2003... (modulo any 2003-vs-2005 language
> warnings/differences, of course...)
> 
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>  
>> -----Original Message-----
>> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM]
>> Sent: Wednesday, July 18, 2007 7:51 PM
>> To: Dan Fabulich
>> Cc: Ted Neward; build-dev at openjdk.java.net
>> Subject: Re: Errors in windows build?
>>
>>
>> It's been my experience that it's almost impossible to say for sure that
>> all Windows users will be able to build.
>> All we can say is that in one particular case, we know it builds.
>> There are just too many variations with a Windows system's configuration
>> and all the versions of CYGWIN PSDK OS etc.
>> Normally we nail down our Windows build systems once we get them
>> configured and working. Linux and Solaris is much easier to deal with.
>>
>> But I think I understand what you are after, so I will try a build myself
>> once we have the windows binary plugs created.
>> Give me a few days.
>>
>> I'm not exactly sure what the QA procedures are, but we explicitly
>> ruled out any QA Windows OpenJDK build testing initially.
>> The fact that the VS003 compiler on Windows has to be purchased
>> makes it difficult for the QA testing, normally QA people don't have to
>> "compile" anything. ;^)
>> Someday soon we can get it going with the free VS2005 compilers, but for
>> now you really need VS2003.
>>
>> -kto
>>
>> Dan Fabulich wrote:
>>> Thanks for your remarks, Kelly.
>>>
>>> I'd like to make a remark/request here.  It's clear that the Windows
>>> OpenJDK build didn't go through any QA, in light of the fact that it
>>> can't possibly succeed without t2k.lib.  In light of that, I'd say that
>>> there's no reason to assume that the rest of the build works as
>>> documented, either.  There could well be bugs in the build scripts or in
>>> the documentation that make it impossible to complete the build.
>>>
>>> Would it be possible for someone at Sun (ideally a QA engineer) to grab
>>> a copy of the real binary plugs, add a copy of t2k.lib in the
>>> appropriate directory and then build OpenJDK following the directions
>>> from the README, (using Cygwin rather than MKS, etc.)?
>>>
>>> What I'm looking for is for someone at Sun to say "works for me!"
>>> Nobody's said that yet in any e-mail that I can find, and that worries
>> me.
>>> -Dan
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007
>> 6:30 PM
>>
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007
> 6:30 PM
>  
>