I do recall that a large part of the problem is that the Visual Studio
compiler uses default filenames that are generic names, so that if GNU
make does try and compile two different files, they can end up trying to
write to the same file, not good.
So it may not be GNU make's fault in all cases, more of a makefile and
compile line issue.
I recall having to make sure that each compile line included specifying
unique paths for every file created by the compilation.
I did this when I was trying to get COMPILE_APPROACH=parallel and
the ALT_PARALLEL_COMPILE_JOBS feature working on windows in the jdk
makefiles. The default on windows is COMPILE_APPROACH=normal, or one
compile at a time. Using parallel on windows just didn't seem to give
much benefit, not exactly sure why.
-kto
Kelly O'Hair wrote:
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
