Building OpenJDK 7 on Windows XP

[Kelly O'Hair]

On Windows, I don't think gmake -j is used by default, unless you used it
yourself. The jdk makefiles won't use it, and hotspot is built with NMAKE
on windows.

I have never seen the parallel job feature of GNU make work on windows,
or work very well, I always avoid it.

-kto

Rob Ross wrote:
> Well I'm happy to report I finally got the full build to work, although 
> it took another 15 hours or so.
> 
> The last two big issues I encountered:
> 
> 1. Unfamiliarity with the freetype project, so had to figure out what 
> needed to be built. This project is rather complicated. It supports 
> building on at least 11 platforms, and allows for multiple 
> compilers/environments on many of these platforms. There are 14 
> different build systems supported on Windows alone!
> 
> Also, this project is highly configurable, and you can build it with 
> support for many optional features. So someone from the OpenJDK 
> architecture team will have to decide what is officially included in 
> this library when it is built for the OpenJDK project. And the build 
> code for it will have to be included in the jdk7 Makefile system.
> 
> I was able to build it by tweaking the VC 8 file included, and opening 
> in VS .Net 2003. I compiled from within VS, then ran the link script I 
> found via a link in this list's archive to create the freetype.dll and 
> freetype.lib. The "aha" moment was when I realized there were actually 
> TWO .lib files being created, a large static one aroung 800K, and a 
> smaller one around 40K. I needed to use the smaller one along with the dll.
> 
> 2. This is most likely a cygwin issue, but I continually experienced 
> deadlocks/starvation of the spawned gmake processes. cygwin's gmake 
> seems to ignore the -j option. At any one time I could have a bash 
> process, a few shell processes, and up to 9 gmake processes running. I 
> could easily tell when a deadlock occurred - my computer would go from 
> sounding like a jet engine to being totally quiet. Then I tried to guess 
> what gmake process was the oldest (not sure if window's task manager 
> sorts them by process ID or creation time, so this is just a guess) and 
> killed that one, and then the build would continue, but obviously with 
> errors as some task was not completed.
> 
> I had to try to rebuild more than 5 times before it finally got through 
> it all. But in the end it completed with no errors.
> 
> java -version worked! Good start
> 
> java HelloWorld worked! Getting better.
> 
> Going for it, I tried SwingSet2 and Java2D demos from the 1.6 JDK.. AND 
> THEY WORKED!
> 
> I did get an error in the Java2D demo complaining about missing a JPEG 
> decoder, but I was too happy the build had worked to really worry about 
> that right now.
> 
> So add another success story to this list.
> 
> 
> Rob Ross, Lead Software Engineer
> E! Networks
> 
> ---------------------------------------------------
> "Beware of he who would deny you access to information, for in his heart 
> he dreams himself your master." -- Commissioner Pravin Lal
> 
> 
> 
> On May 19, 2008, at 8:44 AM, Kelly O'Hair wrote:
> 
>>
>>
>> Rob Ross wrote:
>>> Hi there everyone.
>>> This will officially be my first email to the OpenJDK project.
>>
>> Welcome. I actually appreciate the email, some comments below.
>>
>>> I got to attend a couple of sessions/BOFs at JavaOne2008 about 
>>> OpenJDK and my interest was piqued. I've been playing with the build 
>>> for the last week. (A more accurate description would be, "yanking my 
>>> hair out and cursing my computer quite often", but I supposed it's 
>>> part of the learning curve.)
>>
>> You did pick the most difficult platform you know. ;^)
>>
>> These are the notes and action items I see from your comments:
>>
>> 1. assembling the prerequisite software
>>   - VS .Net 2003  -  Will be changing soon to a newer VC compiler, and if
>>     at all possible the free one.
>>   - Ant is a requirement, I'll fix the Build README, findbugs is not 
>> strictly
>>     a requirement, it's under discussion, I had hoped to use it as 
>> part of the build.
>>     I may be removing the sanity check on findbugs.
>>   - Cygwin is a bit of a challenge, it changes/updates rather often, I'll
>>     try and correct the references to the packages you mention, but
>>     it's like the different Linux packages, sometimes all I can give 
>> is hints.
>>   - The Build README should have some references to the older cygwin 
>> 'make'
>>     now, but I'll double check. I kind of hoped it would fix itself 
>> someday. :^(
>>   - Freetype is new to many of us, I use a freetype that someone else 
>> built
>>     so I have never experienced building it myself.
>>     I will try and look into this and see if I can document it better.
>>
>> 2. Mercurial
>>   - CVS/Subversion users seem to have trouble understanding the 
>> distributed
>>     nature of Mercurial. I'd recommend looking at the first few chapters
>>     of the Mercurial book: http://hgbook.red-bean.com/hgbook.html
>>
>> 3. Setting up the ALT_* environment variables
>>   - If I didn't document this I should have, my apologies, but I 
>> encourage
>>     all ALT_* variables to use the C:/ style of paths, not C:\ and 
>> definitely
>>     not the /cygdrive/ style paths.
>>     The makefiles try and turn the C:\ paths into C:/, but using the 
>> cygwin
>>     paths are more difficult to deal with.
>>     The problem is that some of the exe's we use understand these 
>> paths and
>>     some don't, almost everything understands C:/, and avoiding the 
>> use of
>>     \ characters in shell scripts and Makefiles is a very sane thing 
>> to do.
>>     Making matters worse, the cygwin 'make' that stopped working with C:
>>     paths for a while, hopefully this gets fixed someday.
>>     Of course cygwin PATH must use ':' characters to separate paths, so
>>     you have to use /cygdrive/ paths in PATH.
>>     The LIB and INCLUDE env variables belong to the VS2003 compiler and
>>     they use a ';' separator and need the C:/ paths.
>>     See my blog:
>>        http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and
>>
>> I suspect that your experience with MacOS X will not be the same as 
>> Windows.
>>
>> Thanks for taking the time to make the comments.
>>
>> -kto
>>
>>> I was finally able to get "make sanity" to pass this evening, and I 
>>> felt quite pleased with myself. However, I have no expectations that 
>>> this will actually build now - but I still consider this a milestone 
>>> victory.
>>> Some of the difficulties I encountered were
>>> 1. Just assembling the prerequisite software
>>> The jdk7/README-builds.html actually does a fairly good job of 
>>> listing everything needed. But I'm not a Windows developer, so 
>>> finding a copy of VS .Net 2003 was a little challenging. Luckily that 
>>> install process was pretty simple. The build generates a warning if 
>>> Ant and FindBugs aren't locatable; those were easy to install but 
>>> perhaps you should add these programs to the list of requirements in 
>>> the README. Cygwin was also
>>> pretty easy to install after spending a little time reading up on it. 
>>> Finding an earlier version of make (gmake) was a little hard, but I 
>>> see now there are links in the mailing list archive so that would be 
>>> useful to add a link to the README as well.  Some of the 
>>> Categories/package names you gave for the particular cygwin utilities 
>>> needed may be out of date. Zip and Unzip are found in the Archive 
>>> category, not Utils as described in the README. "Free" is listed as 
>>> being in Utils but it's actually part of the "procps" package, under 
>>> the System category. And there isn't an "awk" implementation, but 
>>> there is a gawk. Freetype was the bane of my existence for 3 days. I 
>>> never could get the "stock" build scripts to work with the version 
>>> you stated was needed (2.3.0), and what was available to be 
>>> downloaded (2.3.5). I could not figure out how to build it from 
>>> source either via DOS/windows or cygwin. So I ended up downloading 
>>> the binary setup executable, which contained freetype.lib, 
>>> freetype6.dll, and zlib1.dll, and a freetype.dll.a that was a red 
>>> herring. I modified the Makefile for the freetypecheck tool to change 
>>> the name of the expected dll from "freetype.dll" to "freetype6.dll", 
>>> and added its dependent "zlib1.dll" to the copy command. Not a very 
>>> portable solution I know, but I just wanted to get this thing to 
>>> work! How is everyone else getting this to compile?
>>> 2. Mercurial - well, it's new, and a little more complicated than 
>>> CVS/SVN, but I think I'll get the hang of it. I fcloned from the jdk7 
>>> master forest, (using the forest extension) yesterday, so I have the 
>>> latest code (baring any changes in the last day). It will be a while 
>>> before I even have to worry about wanting to submit anything back 
>>> upstream, so I should be more comfortable with how it all works by then.
>>> 3. Setting up the ALT_* environment variables
>>> The hardest part, and mostly trial-and-error, was determining what 
>>> variables needed to use the cygwin path syntax, and what needed to 
>>> use the normal Windows path syntax, and what needed to be 
>>> "shortcutted" by using the cygpath utility. This was mind numbingly 
>>> frustrating!!!! I found an email from Tim Bell that included his 
>>> sample script that was quite helpful in getting the right directories 
>>> from the VS .Net 2003 install into the PATH, LIB, and INCLUDE 
>>> variables, with the right syntax. As I was writing this email my 
>>> initial "gmake all" build failed, due to javac not being able to find 
>>> the binary plugins I had specified in ALT_BINARY_PLUGINS_PATH. It 
>>> seems THAT one needs to be a java IO file path! So now there are 
>>> THREE different path syntaxes in use in this script file :)
>>> Anyway, I just wanted to share my experiences building the OpenJDK 7 
>>> on Windows.
>>> Ironically, I'm only doing this to get some practice on the existing 
>>> build process. My ultimate goal is to port the OpenJDK 7 to Mac OS X, 
>>> as a full native app. I'm doing some preliminary analysis on the 
>>> existing code base to determine all calls to native methods, to get  
>>> a sense of the scope. For example, there are currently about 421 
>>> native method calls in the jdk/src/share classes. The Windows 
>>> implementation classes make 210 native calls, and the Solaris 
>>> implementation makes 299. But the first task would be to integrate 
>>> Mac OS build targets into the OpenJDK 7 project, so it can be built 
>>> on that platform. (Of course, it won't actually run without any 
>>> native implementation - that's step #2.) But I'll be making a more 
>>> formal presentation/declaration/request for sponsorship/ at a later 
>>> time.
>>> Rob Ross
>