 |
Building the JDK 6.0 on Windows XP
Posted by kellyohair on October 12, 2005 at 01:14 PM | Comments (3)
In my blog at blogs.sun I talked about
building the JDK 6.0
but I must confess, most of the effort is in just getting your
machine setup, that alone should put you up for a JDK medal of honor.
Once a Windows XP machine has the C++ compiler installed and cygwin installed, the rest is fairly easy.
Of course that's easy for me to say, I've built it so many times
I think I might be going build blind. :^)
First off I would like to thank all the people that have posted
forum topics on the build issues, and/or sent me email on some of
the problems. If I have missed your posting, please comment on this
blog or put a reply on the forum posting asking 'What's up with this?'. I do what I can, but I am only human, or so I'm told. ;^)
Over the past many months we have been trying to simplify both the machine
setup and the build procedures, especially on Windows, and
we have met with some success.
There are limitations in what we can do in terms of re-distribution
of some components, but we are investigating all avenues.
Expect some updates to the build documentation in the next few months
as we gear down on actual makefile changes and
concentrate on improving the
build documentation.
If you have suggestions on improving these documents, please let us know.
Here are the basic Windows build machine requirements we currently
have, with some additional words on what is happening in that area:
-
Visual Studio .NET 2003 Professional (C++ compiler and various components)
-
We are trying to make it possible and easier for someone to use a
different C++ compiler (which should be considered a significant
task by the way, do NOT underestimate this)
but we have not finished this setup,
there is more work to do in this area.
Several people have asked about using different compilers,
but I don't know of anyone that has successfully used a different
compiler to completely build the JDK,
if you have, please let us know.
Eventually, the idea would be to create a j2se/make/common/shared/Compiler-XXX.gmk file
for every possible compiler that could build the JDK, or at least
allow for it.
The file j2se/make/common/shared/Compiler.gmk would
then control what is the default compiler we expect, and again,
this isn't completely setup yet, be kind.
Keep in mind we (Sun) cannot possible guarantee every
compiler setup this way will be able to build and work all the time,
that would be pretty impossible for us to do, we would need your help.
As to what default compiler we choose, that's a performance,
quality of code, and availability issue that would be decided
after some pretty long testing and measurement investigations.
Don't expect any major changes on this front.
-
Money, is one word that many people have pointed out is a
problem with this C++ compiler issue, 'Why do they have to BUY a compiler'? Or another
question is
'Why do I need a C++ compiler at all?', which is a perfectly
understandable question.
I have been experimenting with a way to build the JDK without
having a C++ compiler, the basic idea was to be able to do something like:
make IMPORT_NATIVE_BINARIES=true when
building, and all the DLL or .so shared libraries would be copied in
from a pre-built JDK 6.0 (of the same vintage, e.g. same build number) designated with ALT_JDK_IMPORT_PATH.
Currently this is commonly done with the Hotspot VM files JVM.DLL or
libjvm.so, when building the JDK, avoiding the building the VM's.
This idea just takes it a step further and tries to apply it to
all the native libraries.
This feature isn't working quite yet, and it won't help anyone
changing native code or native interfaces, so it will have
limitations as to what you could change in the JDK.
-
DirectX SDK Version 9
-
We really haven't a choice on this one, you must get it from the
Microsoft Site and follow the install instructions.
-
MSLU
(UNICOWS.dll) is needed, but not used on Windows XP.
-
This is needed to create 32bit builds for older Windows machines, but
really isn't necessary when building on Windows XP for Windows XP
and newer, so we may try and relax this requirement when it is obvious
that your build isn't targeted at Windows 98/2000, which as I understand
it is the only place that requires this library.
Since we have some code that actually makes calls to the
functions in this library, this is probably more than simple makefile
work to limit this dependency.
-
We are restricted from re-distributing this UNICOWS.DLL except in
our binary downloads, but that brings up an interesting point.
The JDK 5.0 download does include this file, and an alternative
to downloading this file from the website would be to just use
the one in the JDK 5.0 tree. Unfortunately, it's a slightly older
version, but seems to be sufficient in many cases, especially on
Windows XP which doesn't need it anyway.
Better is just downloading the pre-built JDK 6.0 that matches the
sources you are trying to build, it has the UNICOWS.DLL you need.
This goes along with the ALT_JDK_IMPORT_PATH discussion above,
maybe IMPORT_NATIVE_BINARIES=true should trigger this file coming
from ALT_JDK_IMPORT_PATH area and then the MSLU
download isn't necessary.
-
CYGWIN or Unix utilities are needed (MKS can be used but is no longer required).
-
A current problem right now is knowing what parts of CYGWIN are needed. We need cpio, zip, unzip, make, etc, but
trying to figure this out during the cygwin install is difficult.
I've just been lazy and installed everything, but this takes a very
long time. We will try and provide better documentation on this.
On our list of potential simplifications on the build machine setup
is investigating creating a bundle of the necessary cygwin
packages for re-distribution so that these steps could be easier.
But it would need to be a separate download bundle to make sure
we follow all the cygwin requirements on re-distribution.
If you think this is a good idea, please let us know, or if you
think it's a waste of time, please make your voice heard.
This is probably one of the lower priority build issues for us,
part of me says that just referring to the CYGWIN site is fine.
-
JDK 5.0 is needed to build JDK 6.0.
-
This is called the BOOTDIR JDK, and
actually, the latest pre-built JDK 6.0 could be used as the BOOTDIR.
It's not a standard practice, but will work, if it didn't we'd
have a P1 bug against JDK 6.0 real quick. ;^)
So this download could be optional ALT_BOOTDIR and
ALT_JDK_IMPORT_PATH could point at the same JDK 6.0 build.
So what about simplification of the actual build?
Well
last time I tried
I needed to:
-
Download the pre-built
JDK 6.0
and install it.
-
Download the
Mozilla Headers File
bundle and un-jar it.
-
Download the
two JDK 6.0 source bundles
and un-jar them into the same directory.
-
Make sure it's all positioned properly or the ALT variables are set.
-
We have been trying to minimize the number of ALT variables
that need to be set.
Currently the makefiles should be able to find many components
automatically, e.g. the compilers, Direct X 9, CYGWIN, and even
the formally installed JDK's should be found automatically now.
Since my original blog, we have tried to remove the need to set
ALT_BOOTDIR and ALT_DEVTOOLS_DIR when CYGWIN is used.
-
Use:
cd control/make && make dev-sanity
to verify everything is ok (extra points if you get it right
the first time),
And: cd control/make && make dev
-
Or perhaps someday you can skip the C++ compiler install completely
and just
make IMPORT_NATIVE_BINARIES=true .
Once a JDK has been completely built, depending on the area
you may be concentrating on, there are shortcuts and alternatives
to the makefiles when incrementally re-building portions of
the workspace. I'll try and blog on that in the future.
A short note on dependencies and major build re-structuring.
Several people have suggested
complete re-writes of the makefiles, or conversion to other
build tools.
I don't really expect this to happen, the
many dependencies on the installed components and the
cross dependencies of all the makefiles upon each other make this
extremely risky and labor intensive.
These JDK makefiles are unique, as is the build process necessary
to create the JDK.
The mixture of the native code, the Java code,
the Java compiler bootstrap, the builds of the JNI libraries,
and the creation of all the different install bundles
for all the flavors of Windows, Solaris, and Linux,
just make this an extremely unique build process.
We have and will continue to improve the existing system, and
perhaps evolve portions of the build to enable other ways to
build the JDK, but don't expect a wholesale re-write.
This will be an evolutionary process, not a revolutionary one.
Just making sure people's expectations are set appropriately.
Hopefully you have found this informative, and once again,
please let us know what problems you are having with the builds.
|
