OpenJDK 6 Build README

+ This document is specific to OpenJDK 6, which has some
+ very minor differences in the build requirements over
+ the OpenJDK 7 sources,
+ e.g. OpenJDK 6 requires access to Motif files.
+ Where there are differences they should stand out,
+ like this block of text does.
+

+ This file often describes specific requirements for what we call the
+ "minimum build environments" (MBE) for the JDK.
+ Building with the MBE will generate the most compatible
+ bits that install on, and run correctly on, the most variations
+ of the same base OS and hardware architecture.
+ These usually represent what is often called the
+ least common denominator platforms.
+ It is understood that most developers will NOT be using these
+ specific platforms, and in fact creating these specific platforms
+ may be difficult due to the age of some of this software.
+

+ The minimum OS and C/C++ compiler versions needed for building the
+ OpenJDK:
+

+ In addition to needing the Bootstrap JDK and the Binary Plugs,
+ when building on Ubuntu you will need to
+ make sure certain packages are installed.
+ In particular, certain X11 packages, make, m4, gawk, gcc 4,
+ binutils, cups, freetype
+ and alsa.
+
+

Ubuntu 6.06

+

+ The following list of packages for Ubuntu 6.06 is a working set that
+ does appear to work.
+

+ Note that it's quite possible that some of these
+ packages are not required, so anyone discovering that some of the
+ packages listed below are NOT required,
+ please let the
+ OpenJDK
+ team know.
+

+ All the packages below can be installed with the
+ Synaptic Package manager provided with the base Ubuntu 6.06 release.
+

- This file often describes specific requirements for what we call the
- "minimum build environments" (MBE) for the JDK.
- Building with the MBE will generate the most compatible
- bits that install on, and run correctly on, the most variations
- of the same base OS and hardware architecture.
- These usually represent what is often called the
- least common denominator platforms.
- It is understood that most developers will NOT be using these
- specific platforms, and in fact creating these specific platforms
- may be difficult due to the age of some of this software.
-

-
-

- The minimum OS and C/C++ compiler versions needed for building the
- OpenJDK:
-

- In addition to needing the Bootstrap JDK and the Binary Plugs,
- when building on Ubuntu you will need to
- make sure certain packages are installed.
- In particular, certain X11 packages, make, m4, gawk, gcc 4,
- binutils, cups, freetype
- and alsa.
-
-

Ubuntu 6.06

-
-

- The following list of packages for Ubuntu 6.06 is a working set that
- does appear to work.
-
-

- Note that it's quite possible that some of these
- packages are not required, so anyone discovering that some of the
- packages listed below are NOT required,
- please let the
- OpenJDK
- team know.
-

- All the packages below can be installed with the
- Synaptic Package manager provided with the base Ubuntu 6.06 release.
-
-

- The source code for the OpenJDK is delivered in a set of
- directories:
- hotspot,
- langtools,
- corba,
- jaxws,
- jaxp,
- and
- jdk.
- The hotspot directory contains the source code and make
- files for building the OpenJDK Hotspot Virtual Machine.
- The langtools directory contains the source code and make
- files for building the OpenJDK javac and language tools.
- The corba directory contains the source code and make
- files for building the OpenJDK Corba files.
- The jaxws directory contains the source code and make
- files for building the OpenJDK JAXWS files.
- The jaxp directory contains the source code and make
- files for building the OpenJDK JAXP files.
- The jdk directory contains the source code and make files for
- building the OpenJDK runtime libraries and misc files.
- The top level Makefile (or control/Makefile)
- is used to build the entire OpenJDK.
-

- Building the
- OpenJDK
- is done with a gmake
- command line and various
- environment or make variable settings that direct the make rules
- to where various components have been installed.
- Where possible the makefiles will attempt to located the various
- components in the default locations or any component specific
- variable settings.
- When the normal defaults fail or components cannot be found,
- the various
- ALT_* variables (alternates)
- can be used to help the makefiles locate components.
-

- Refer to the bash/sh/ksh setup file
- jdk/make/jdk_generic_profile.sh
- if you need help in setting up your environment variables.
- A build could be as simple as:
-

-

+

+
+

Ubuntu 7.04

+

+ Using the Synaptic Package Manager, download the following
+ packages (double indented packages are automatically aquired
+ due to package dependencies):
+

+ The source code for the OpenJDK is delivered in a set of
+ directories:
+ hotspot,
+ langtools,
+ corba,
+ jaxws,
+ jaxp,
+ and
+ jdk.
+ The hotspot directory contains the source code and make
+ files for building the OpenJDK Hotspot Virtual Machine.
+ The langtools directory contains the source code and make
+ files for building the OpenJDK javac and language tools.
+ The corba directory contains the source code and make
+ files for building the OpenJDK Corba files.
+ The jaxws directory contains the source code and make
+ files for building the OpenJDK JAXWS files.
+ The jaxp directory contains the source code and make
+ files for building the OpenJDK JAXP files.
+ The jdk directory contains the source code and make files for
+ building the OpenJDK runtime libraries and misc files.
+ The top level Makefile
+ is used to build the entire OpenJDK.
+

+ Building the OpenJDK
+ is done with a gmake
+ command line and various
+ environment or make variable settings that direct the make rules
+ to where various components have been installed.
+ Where possible the makefiles will attempt to located the various
+ components in the default locations or any component specific
+ variable settings.
+ When the normal defaults fail or components cannot be found,
+ the various
+ ALT_* variables (alternates)
+ can be used to help the makefiles locate components.
+

+ Refer to the bash/sh/ksh setup file
+ jdk/make/jdk_generic_profile.sh
+ if you need help in setting up your environment variables.
+ A build could be as simple as:
+

+

bash
. jdk/make/jdk_generic_profile.sh
gmake sanity && gmake
-

-

-

- Of course ksh or sh would work too.
- But some customization will probably be necessary.
- The sanity rule will make some basic checks on build
- dependencies and generate appropriate warning messages
- regarding missing, out of date, or newer than expected components
- found on your system.
-

- The Makefiles in the
- OpenJDK
- are only valid when used with the
- GNU version of the utility command make
- (gmake).
- A few notes about using GNU make:
-

-

- In general, you need GNU make version 3.78.1 or newer.
-

-

- Place the location of the GNU make binary in the PATH.
-

-

- Linux:
- The /usr/bin/make command should work fine for you.
-

-

- Solaris:
- Do NOT use /usr/bin/make on Solaris.
- If your Solaris system has the software
- from the Solaris Companion CD installed,
- you should use gmake
- which will be located in either the /opt/sfw/bin or
- /usr/sfw/bin directory.
-

-

+
+

+

+ Of course ksh or sh would work too.
+ But some customization will probably be necessary.
+ The sanity rule will make some basic checks on build
+ dependencies and generate appropriate warning messages
+ regarding missing, out of date, or newer than expected components
+ found on your system.
+

+ The Makefiles in the OpenJDK are only valid when used with the
+ GNU version of the utility command make
+ (gmake).
+ A few notes about using GNU make:
+

+

+ In general, you need GNU make version 3.78.1 or newer.
+

+

+ Place the location of the GNU make binary in the PATH.
+

+

+ Linux:
+ The /usr/bin/make command should work fine for you.
+

+

+ Solaris:
+ Do NOT use /usr/bin/make on Solaris.
+ If your Solaris system has the software
+ from the Solaris Companion CD installed,
+ you should use gmake
+ which will be located in either the /opt/sfw/bin or
+ /usr/sfw/bin directory.
+

+

+ Windows:
+ Make sure you start your build inside a bash/sh/ksh shell.
+
+ WARNING: Watch out for make version 3.81, it may
+ not work due to a lack of support for drive letter paths
+ like C:/. See
+ section on gmake.
+ Use a 3.80 version, or find a newer
+ version that has this problem fixed.
+ The older 3.80 version of make.exe can be downloaded with this
+
+ link.
+ Also see the
+
+ mozilla developer center
+ on this topic.
+

+ i586 only:
+ The minimum recommended hardware for building the Linux version
+ is a Pentium class processor or better, at least 256 MB of RAM, and
+ approximately 1.5 GB of free disk space.
+

+ X64 only:
+ The minimum recommended hardware for building the Linux
+ version is an AMD Opteron class processor, at least 512 MB of RAM, and
+ approximately 4 GB of free disk space.
+

+ The build will use the tools contained in
+ /bin and
+ /usr/bin
+ of a standard installation of the Linux operating environment.
+ You should ensure that these directories are in your
+ PATH.
+

+ Note that some Linux systems have a habit of pre-populating
+ your environment variables for you, for example JAVA_HOME
+ might get pre-defined for you to refer to the JDK installed on
+ your Linux system.
+ You will need to unset JAVA_HOME.
+ It's a good idea to run env and verify the
+ environment variables you are getting from the default system
+ settings make sense for building the
+ OpenJDK.
+

+ The minimum recommended hardware for building the
+ Solaris SPARC version is an UltraSPARC with 512 MB of RAM.
+ For building
+ the Solaris x86 version, a Pentium class processor or better and at
+ least 512 MB of RAM are recommended.
+ Approximately 1.4 GB of free disk
+ space is needed for a 32-bit build.
+

+ If you are building the 64bit version, you should
+ run the command "isainfo -v" to verify that you have a
+ 64-bit installation, it should say sparcv9 or
+ amd64.
+ An additional 7 GB of free disk space is needed
+ for a 64-bit build.
+

+ The build uses the tools contained in /usr/ccs/bin
+ and /usr/bin of a standard developer or full installation of
+ the Solaris operating environment.
+

+ Solaris patches specific to the JDK can be downloaded from the
+
+ SunSolve JDK Solaris patches download page.
+ You should ensure that the latest patch cluster for
+ your version of the Solaris operating environment has also
+ been installed.
+

+ i586 only:
+ The minimum recommended hardware for building the 32bit or X86
+ Windows version is an Pentium class processor or better, at least
+ 512 MB of RAM, and approximately 600 MB of free disk space.
+
+ NOTE: The Windows 2000 build machines need to use the
+ file system NTFS.
+ Build machines formatted to FAT32 will not work
+ because FAT32 doesn't support case-sensitivity in file names.
+
+

+ X64 only:
+ The minimum recommended hardware for building
+ the Windows X64 version is an AMD Opteron class processor, at least 1
+ GB of RAM, and approximately 10 GB of free disk space.
+

Windows:
- Make sure you start your build inside a bash/sh/ksh shell.
-
- WARNING: Watch out for make version 3.81, it may
- not work due to a lack of support for drive letter paths
- like C:/. Use a 3.80 version, or find a newer
- version that has this problem fixed.
-
-
-

- i586 only:
- The minimum recommended hardware for building the Linux version
- is a Pentium class processor or better, at least 256 MB of RAM, and
- approximately 1.5 GB of free disk space.
-

- X64 only:
- The minimum recommended hardware for building the Linux
- version is an AMD Opteron class processor, at least 512 MB of RAM, and
- approximately 4 GB of free disk space.
-

- The build will use the tools contained in
- /bin and
- /usr/bin
- of a standard installation of the Linux operating environment.
- You should ensure that these directories are in your
- PATH.
-

- Note that some Linux systems have a habit of pre-populating
- your environment variables for you, for example JAVA_HOME
- might get pre-defined for you to refer to the JDK installed on
- your Linux system.
- You will need to unset JAVA_HOME.
- It's a good idea to run env and verify the
- environment variables you are getting from the default system
- settings make sense for building the
- OpenJDK.
-

- The minimum recommended hardware for building the
- Solaris SPARC version is an UltraSPARC with 512 MB of RAM.
- For building
- the Solaris x86 version, a Pentium class processor or better and at
- least 128 MB of RAM are recommended.
- Approximately 1.4 GB of free disk
- space is needed for a 32-bit build.
-

- If you are building the 64bit version, you should
- run the command "isainfo -v" to verify that you have a
- 64-bit installation.
- An additional 7 GB of free disk space is needed
- for a 64-bit build.
-

- The build uses the tools contained in /usr/ccs/bin
- and /usr/bin of a standard developer or full installation of
- the Solaris operating environment.
-

- i586 only:
- The minimum recommended hardware for building the 32bit or X86
- Windows version is an Pentium class processor or better, at least
- 512 MB of RAM, and approximately 600 MB of free disk space.
-
- NOTE: The Windows 2000 build machines need to use the
- file system NTFS.
- Build machines formatted to FAT32 will not work
- because FAT32 doesn't support case-sensitivity in file names.
-
-

- X64 only:
- The minimum recommended hardware for building
- the Windows X64 version is an AMD Opteron class processor, at least 1
- GB of RAM, and approximately 10 GB of free disk space.
-

- Windows:
- Note that GNU make is a historic utility and is based very
- heavily on shell scripting, so it does not tolerate the Windows habit
- of having spaces in pathnames or the use of the \characters in pathnames.
- Luckily on most Windows systems, you can use /instead of \, and
- there is always a 'short' pathname without spaces for any path that
- contains spaces.
- Unfortunately, this short pathname can be somewhat dynamic and the
- formula is difficult to explain.
- You can use cygpath utility to map pathnames with spaces
- or the \character into the C:/ style of pathname
- (called 'mixed'), e.g.
- cygpath -s -m "path".
-

- The makefiles will try to translate any pathnames supplied
- to it into the C:/ style automatically.
-

- Note that use of CYGWIN creates a unique problem with regards to
- setting PATH. Normally on Windows
- the PATH variable contains directories
- separated with the ";" character (Solaris and Linux uses ":").
- With CYGWIN, it uses ":", but that means that paths like "C:/path"
- cannot be placed in the CYGWIN version of PATH and
- instead CYGWIN uses something like /cygdrive/c/path
- which CYGWIN understands, but only CYGWIN understands.
- So be careful with paths on Windows.
-

- Depending on the platform, the
- OpenJDK
- build process has some basic
- dependencies on components not part of the
- OpenJDK
- sources.
- Some of these are specific to a platform, some even specific to
- an architecture.
- Each dependency will have a set of ALT variables that can be set
- to tell the makefiles where to locate the component.
- In most cases setting these ALT variables may not be necessary
- and the makefiles will find defaults on the system in standard
- install locations or through component specific variables.
-
-

- All
- OpenJDK
- builds require access to the previously released
- JDK 6, this is often called a bootstrap JDK.
- The JDK 6 binaries can be downloaded from Sun's
- JDK 6 download site.
- For build performance reasons
- is very important that this bootstrap JDK be made available on the
- local disk of the machine doing the build.
- You should always set
- ALT_BOOTDIR
- to point to the location of
- the bootstrap JDK installation, this is the directory pathname
- that contains a bin, lib, and include
- It's also a good idea to also place its bin directory
- in the PATH environment variable, although it's
- not required.
-

- Solaris:
- Some pre-installed JDK images may be available to you in the
- directory /usr/jdk/instances.
- If you don't set
- ALT_BOOTDIR
- the makefiles will look in that location for a JDK it can use.
-

- Not all of the source code that makes up the JDK is available
- under an open-source license.
- In order to build an OpenJDK binary from source code,
- you must first download and install the appropriate
- binary plug bundles from the OpenJDK, go to the
- OpenJDK site and select
- the "Bundles(6)" link.
- During the OpenJDK build process these "binary plugs"
- for the encumbered components will be copied into your
- resulting OpenJDK binary build image.
- These binary plug files are only for the purpose of
- building an OpenJDK binary.
- Make sure you set
- ALT_BINARY_PLUGS_PATH
- to the root of this installation.
-

- See
- www.wikipedia.org/wiki/CAcert
- for a better understanding of the Certificate Authority (CA).
- A certificates file named "cacerts"
- represents a system-wide keystore with CA certificates.
- In JDK and JRE
- binary bundles, the "cacerts" file contains root CA certificates from
- several public CAs (e.g., VeriSign, Thawte, and Baltimore).
- The source contain a cacerts file
- without CA root certificates.
- Formal JDK builders will need to secure
- permission from each public CA and include the certificates into their
- own custom cacerts file.
- Failure to provide a populated cacerts file
- will result in verification errors of a certificate chain during runtime.
- The variable
- ALT_CACERTS_FILE
- can be used to override the default location of the
- cacerts file that will get placed in your build.
- By default an empty cacerts file is provided and that should be
- fine for most JDK developers.
-

-
-
- Linux gcc/binutils
-
-
+ Note that GNU make is a historic utility and is based very
+ heavily on shell scripting, so it does not tolerate the Windows habit
+ of having spaces in pathnames or the use of the \characters in pathnames.
+ Luckily on most Windows systems, you can use /instead of \, and
+ there is always a 'short' pathname without spaces for any path that
+ contains spaces.
+ Unfortunately, this short pathname can be somewhat dynamic and the
+ formula is difficult to explain.
+ You can use cygpath utility to map pathnames with spaces
+ or the \character into the C:/ style of pathname
+ (called 'mixed'), e.g.
+ cygpath -s -m "path".
+

+ The makefiles will try to translate any pathnames supplied
+ to it into the C:/ style automatically.
+

+ Note that use of CYGWIN creates a unique problem with regards to
+ setting PATH. Normally on Windows
+ the PATH variable contains directories
+ separated with the ";" character (Solaris and Linux uses ":").
+ With CYGWIN, it uses ":", but that means that paths like "C:/path"
+ cannot be placed in the CYGWIN version of PATH and
+ instead CYGWIN uses something like /cygdrive/c/path
+ which CYGWIN understands, but only CYGWIN understands.
+ So be careful with paths on Windows.
+

- Set
- ALT_COMPILER_PATH
- to point to the location of
- the compiler binaries, and place this location in the PATH.
-

- The Sun Studio Express compilers at:
-
- Sun Studio Express Download site
- are also an option, although these compilers have not
- been extensively used yet.
+ Depending on the platform, the OpenJDK build process has some basic
+ dependencies on components not part of the OpenJDK sources.
+ Some of these are specific to a platform, some even specific to
+ an architecture.
+ Each dependency will have a set of ALT variables that can be set
+ to tell the makefiles where to locate the component.
+ In most cases setting these ALT variables may not be necessary
+ and the makefiles will find defaults on the system in standard
+ install locations or through component specific variables.
+
+

+ All OpenJDK builds require access to the previously released
+ JDK 6, this is often called a bootstrap JDK.
+

+
+ Normally the "boot" JDK is the previously released version
+ of the JDK, so it's unusual for a JDK 6 build like this to
+ require a JDK 6 "boot".
+ Unfortunately, it is currently required due to some JDK 6
+ dependencies in some of the sources.
+

+ The JDK 6 binaries can be downloaded from Sun's
+ JDK 6 download site.
+ For build performance reasons
+ is very important that this bootstrap JDK be made available on the
+ local disk of the machine doing the build.
+ You should always set
+ ALT_BOOTDIR
+ to point to the location of
+ the bootstrap JDK installation, this is the directory pathname
+ that contains a bin, lib, and include
+ It's also a good idea to also place its bin directory
+ in the PATH environment variable, although it's
+ not required.
+

+ Solaris:
+ Some pre-installed JDK images may be available to you in the
+ directory /usr/jdk/instances.
+ If you don't set
+ ALT_BOOTDIR
+ the makefiles will look in that location for a JDK it can use.
+

+ Not all of the source code that makes up the JDK is available
+ under an open-source license.
+ This is a temporary situation and these binary plugs will be
+ replaced with fully open source replacements as soon as possible.
+ So currently, in order to build a complete OpenJDK image,
+ you must first download and install the appropriate
+ binary plug bundles for the OpenJDK, go to the
+ OpenJDK site and select
+ the
+
+
+ "Bundles(6)"
+
+ link and download the binaryplugs for
+ your particular platform.
+ The file downloaded is a jar file that must be extracted by running
+ the jar file with:
+

+
+

+ java -jar jdk-6-ea-plug-bnn-os-arch-dd_month_year.jar
+

+

+ A prompt will be issued for acceptance of these binary plug files.
+ During the OpenJDK build process these "binary plugs"
+ for the encumbered components will be copied into your
+ resulting OpenJDK binary build image.
+ These binary plug files are only for the purpose of
+ building an OpenJDK binary.
+ Make sure you set
+ ALT_BINARY_PLUGS_PATH
+ to the root of this installation.
+

+ The ALT_JDK_IMPORT_PATH
+ setting is only needed if you are not building the entire
+ JDK. For example, if you have built the entire JDK once, and
+ wanted to avoid repeatedly building the Hotspot VM, you could
+ set this to the location of the previous JDK install image
+ and the build will copy the needed files from this import area.
+

+ See
+ http://en.wikipedia.org/wiki/Certificate_Authority
+ for a better understanding of the Certificate Authority (CA).
+ A certificates file named "cacerts"
+ represents a system-wide keystore with CA certificates.
+ In JDK and JRE
+ binary bundles, the "cacerts" file contains root CA certificates from
+ several public CAs (e.g., VeriSign, Thawte, and Baltimore).
+ The source contain a cacerts file
+ without CA root certificates.
+ Formal JDK builders will need to secure
+ permission from each public CA and include the certificates into their
+ own custom cacerts file.
+ Failure to provide a populated cacerts file
+ will result in verification errors of a certificate chain during runtime.
+ The variable
+ ALT_CACERTS_FILE
+ can be used to override the default location of the
+ cacerts file that will get placed in your build.
+ By default an empty cacerts file is provided and that should be
+ fine for most JDK developers.
+

+ The GNU gcc compiler version should be 3.2.2 or newer.
+ The binutils package should be 2.11.93.0.2-11 or newer.
+ The compiler used should be the default compiler installed
+ in /usr/bin.
+

+ Older Linux systems may require a gcc and bunutils update.
+ The Redhat Enterprise Advanced Server 2.1 update 2 system
+ is one of these systems.
+ RedHat Linux users can obtain this binutils package from
+ Redhat web site.
+ You will need to remove the default compiler and binutils
+ packages and install the required packages
+ into the default location on the system.
+ However if you have a new video card driver, like
+ Geforce 4 it is best to use
+ the same compiler as the kernel was built with to
+ build the new video card driver module.
+ So you should build the modules before making this change.
+

+ The 32-bit OpenJDK Windows build
+ requires Microsoft Visual Studio .NET 2003 (VS2003) Professional
+ Edition compiler.
+ The compiler and other tools are expected to reside
+ in the location defined by the variable VS71COMNTOOLS which
+ is set by the Microsoft Visual Studio .NET installer.
+

+ Once the compiler is installed,
+ it is recommended that you run VCVARS32.BAT
+ to set the compiler environment variables
+ MSVCDIR,
+ INCLUDE,
+ LIB, and
+ PATH
+ prior to building the
+ OpenJDK.
+ The above environment variables MUST be set.
+

+ The Microsoft Visual Studio .NET 2005 (VS2005) compiler
+ will not work at this time due to the new runtime dll
+ and the manifest requirements.
+

+ On X64, the Microsoft Platform Software
+ Development Kit (SDK), April 2005 Edition compiler,
+ is required for building the OpenJDK
+ because it contains the C/C++ compiler.
+ You will need to minimally install the Core SDK and
+ the MDAC SDK features of this compiler.
+

+ Once the Platform SDK is installed,
+ it is recommended that you run SetEnv.Cmd /X64
+ to set the compiler environment variables
+ MSSDK,
+ MSTOOLS,
+ INCLUDE,
+ LIB, and
+ PATH
+ prior to building the
+ OpenJDK.
+ The above environment variables MUST be set.
+

+ Note that this compiler may say it's version is a
+ Microsoft Visual Studio .NET 2005 (VS2005), but be careful,
+ it will not match the official VS2005 product.
+ This Platform SDK compiler is only used on X64 builds.
+

+ Version 2.2 (November 3rd 1997) or newer of the zip utility
+ and version 5.12 or newer of the unzip utility is needed
+ to build the JDK.
+ With Solaris, Linux, and Windows CYGWIN, the zip and unzip
+ utilities installed on the system should be fine.
+ Information and the source code for
+ ZIP.EXE and UNZIP.EXE is available on the
+ info-zip web site.
+

+ Solaris:
+ CUPS header files are required for building the
+ OpenJDK on Solaris.
+ The Solaris header files can be obtained by installing
+ the package SFWcups from the Solaris Software
+ Companion CD/DVD, these often will be installed into
+ /opt/sfw/cups.
+

+ Linux:
+ CUPS header files are required for building the
+ OpenJDK on Linux.
+ The Linux header files are usually available from a "cups"
+ development package, it's recommended that you try and use
+ the package provided by the particular version of Linux that
+ you are using.
+

+ The CUPS header files can always be downloaded from
+ www.cups.org.
+ The variable
+ ALT_CUPS_HEADERS_PATH
+ can be used to override the default location of the
+ CUPS Header files.
+

+ Solaris:
+ Normally these files can be found on Solaris systems
+ at /usr/include/Xm, so on Solaris systems no further downloads
+ should be needed.
+

+ Linux:
+ On Linux, your particular Linux distribution may provide a
+ "motif" development package you can install. If this package
+ installs the files into /usr/include/Xm, no further action should
+ be needed.
+ An acceptable version of these Motif header files are
+ available in the source bundle
+
+ openmotif-2.1.30.5p1.tgz
+ from
+ www.openbsd.org.
+ You would need to install the package and set the environment variable
+ ALT_MOTIF_DIR
+ to refer to the top of this installation.
+

+ Version 2.3 or newer of FreeType is required for building the OpenJDK.
+ On Unix systems required files can be available as part of your
+ distribution (while you still may need to upgrade them).
+ Note that you need development version of package that
+ includes both FreeType library and header files.
+

+ You can always download latest FreeType version from the
+ FreeType website.
+

+ Makefiles will try to pick FreeType from /usr/lib and /usr/include.
+ In case it is installed elsewhere you will need to set environment
+ variables
+ ALT_FREETYPE_LIB_PATH
+ and
+ ALT_FREETYPE_HEADERS_PATH
+ to refer to place where library and header files are installed.
+

+ Linux only:
+ Version 0.9.1 or newer of the ALSA files are
+ required for building the OpenJDK on Linux.
+ These Linux files are usually available from an "alsa"
+ of "libasound"
+ development package, it's highly recommended that you try and use
+ the package provided by the particular version of Linux that
+ you are using.
+ The makefiles will check this emit a sanity error if it is
+ missing or the wrong version.
+

+ In particular, older Linux systems will likely not have the
+ right version of ALSA installed, for example
+ Redhat AS 2.1 U2 and SuSE 8.1 do not include a sufficiently
+ recent ALSA distribution.
+ On rpm-based systems, you can see if ALSA is installed by
+ running this command:
+

+ rpm -qa | grep alsa
+

+ Both alsa and alsa-devel packages are needed.
+

+ If your distribution does not come with ALSA, and you can't
+ find ALSA packages built for your particular system,
+ you can try to install the pre-built ALSA rpm packages from
+
+ www.freshrpms.net.
+ Note that installing a newer ALSA could
+ break sound output if an older version of ALSA was previously
+ installed on the system, but it will enable JDK compilation.
+

Windows Specific Dependencies

- The 32-bit
- OpenJDK
- Windows build
- requires Microsoft Visual Studio .NET 2003 (VS2003) Professional
- Edition compiler.
- The compiler and other tools are expected to reside
- in the location defined by the variable VS71COMNTOOLS which
- is set by the Microsoft Visual Studio .NET installer.
-

- Once the compiler is installed,
- it is recommended that you run VCVARS32.BAT
- to set the compiler environment variables
- MSVCDIR,
- INCLUDE,
- LIB, and
- PATH
- prior to building the
- OpenJDK.
- The above environment variables MUST be set.
-

- The Microsoft Visual Studio .NET 2005 (VS2005) compiler
- will not work at this time due to the new runtime dll
- and the manifest requirements.
-

- On X64,
- the Microsoft Platform Software
- Development Kit (SDK), April 2005 Edition compiler, is required for
- building the
- OpenJDK
- because it contains the C/C++ compiler.
- You will need to minimally install the Core SDK and
- the MDAC SDK features of this compiler.
-

- Once the Platform SDK is installed,
- it is recommended that you run SetEnv.Cmd /X64
- to set the compiler environment variables
- MSSDK,
- MSTOOLS,
- INCLUDE,
- LIB, and
- PATH
- prior to building the
- OpenJDK.
- The above environment variables MUST be set.
-

- Note that this compiler may say it's version is a
- Microsoft Visual Studio .NET 2005 (VS2005), but be careful,
- it will not match the official VS2005 product.
- This Platform SDK compiler is only used on X64 builds.
-

- Solaris:
- CUPS header files are required for building the
- OpenJDK on Solaris.
- The Solaris header files can be obtained by installing
- the package SFWcups from the Solaris Software
- Companion CD/DVD, these often will be installed into
- /opt/sfw/cups.
-

- Linux:
- CUPS header files are required for building the
- OpenJDK on Linux.
- The Linux header files are usually available from a "cups"
- development package, it's recommended that you try and use
- the package provided by the particular version of Linux that
- you are using.
-

- The CUPS header files can always be downloaded from
- www.cups.org.
- The variable
- ALT_CUPS_HEADERS_PATH
- can be used to override the default location of the
- CUPS Header files.
-

- Motif headers (not libraries) are required for building the
- OpenJDK.
-

- Solaris:
- Normally these files can be found on Solaris systems
- at /usr/include/Xm, so on Solaris systems no further downloads
- should be needed.
-

- Linux:
- On Linux, your particular Linux distribution may provide a
- "motif" development package you can install. If this package
- installs the files into /usr/include/Xm, no further action should
- be needed.
- An acceptable version of these Motif header files are
- available in the source bundle
-
- openmotif-2.1.30.5p1.tgz
- from
- www.openbsd.org.
- You would need to install the package and set the environment variable
- ALT_MOTIF_DIR
- to refer to the top of this installation.
-

- Version 2.3 or newer of FreeType is required for building the OpenJDK.
- On Unix systems required files can be available as part of your
- distribution (while you still may need to upgrade them).
- Note that you need development version of package that
- includes both FreeType library and header files.
-

-

- You can always download latest FreeType version from the
- FreeType website.
-

-

- Makefiles will try to pick FreeType from /usr/lib and /usr/include.
- In case it is installed elsewhere you will need to set environment
- variables
- ALT_FREETYPE_LIB_PATH
- and
- ALT_FREETYPE_HEADERS_PATH
- to refer to place where library and header files are installed.
-

- Linux only:
- Version 0.9.1 or newer of the ALSA files are
- required for building the
- OpenJDK on Linux.
- These Linux files are usually available from an "alsa"
- of "libasound"
- development package, it's recommended that you try and use
- the package provided by the particular version of Linux that
- you are using.
- The makefiles will check this emit a sanity error if it is
- missing or the wrong version.
- As a last resort you can go to the
-
- Advanced Linux Sound Architecture Site.
-

+ Microsoft DirectX 9.0 SDK (Summer 2004)
+ headers are required for building
+ OpenJDK.
+ This SDK can be downloaded from
+
+ Microsoft DirectX 9.0 SDK (Summer 2004).
+ If the link above becomes obsolete, the SDK can be found from
+ the Microsoft Download Site
+ (search with "DirectX 9.0 SDK Update Summer 2004").
+ The location of this SDK can be set with
+ ALT_DXSDK_PATH
+ but it's normally found via the DirectX environment variable
+ DXSDK_DIR.
+

+ i586 only:
+ The OpenJDK 32bit build requires access to
+ MSVCRT.DLL version 6.00.8337.0 or newer.
+ If the MSVCRT.DLL is not installed in
+ the system32 directory set the
+ ALT_MSVCRT_DLL_PATH
+ variable to the location.
+

+ X64 only:
+ The OpenJDK 64bit build requires access to
+ MSVCRT.DLL version 7.0.3790.0 or newer, which is
+ usually supplied by the
+ Platform SDK.
+ If it is not available from the Platform SDK,
+ set the
+ ALT_MSVCRT_DLL_PATH
+ variable to the location.
+

+ i586 only:
+ The
+ OpenJDK
+ build requires access to
+ MSVCR71.DLL version 7.10.3052.4 or newer which should be
+ supplied by the
+ Visual Studio product
+ If the MSVCR71.DLL is not available from the
+ Visual Studio product
+ set the
+ ALT_MSVCR71_DLL_PATH
+ variable to the location.

+ Once a machine is setup to build the OpenJDK,
+ the steps to create the build are fairly simple.
+ The various ALT settings can either be made into variables
+ or can be supplied on the
+ gmake
+ command.
+
+

- Microsoft DirectX 9.0 SDK (Summer 2004)
- headers are required for building
- OpenJDK.
- This SDK can be downloaded from
-
- Microsoft DirectX 9.0 SDK (Summer 2004).
- If the link above becomes obsolete, the SDK can be found from
- the Microsoft Download Site
- (search with "DirectX 9.0 SDK Update Summer 2004").
- The location of this SDK can be set with
- ALT_DXSDK_PATH
- but it's normally found via the DirectX environment variable
- DXSDK_DIR.
+ Solaris:
+ Note that ARCH_DATA_MODEL is really only needed on Solaris to
+ indicate you want to built the 64-bit version.
+ And before the Solaris 64-bit binaries can be used, they
+ must be merged with the binaries from a separate 32-bit build.
+ The merged binaries may then be used in either 32-bit or 64-bit mode, with
+ the selection occurring at runtime
+ with the -d32 or -d64 options.

+ When the build is completed, you should see the generated
+ binaries and associated files in the j2sdk-image
+ directory in the output directory.
+ The default output directory is
+ build/platform,
+ where platform is one of
+

+

solaris-sparc

+

solaris-sparcv9

+

solaris-i586

+

solaris-amd64

+

linux-i586

+

linux-amd64

+

windows-i586

+

windows-amd64

+

+ In particular, the
+ build/platform/j2sdk-image/bin
+ directory should contain executables for the
+ OpenJDK tools and utilities.

- i586 only:
- The
- OpenJDK
- 32bit build requires
- access to MSVCRT.DLL
- version 6.00.8337.0 or newer.
- If the MSVCRT.DLL is not installed in
- the system32 directory set the
- ALT_MSVCRT_DLL_PATH
- variable to the location.
-

- X64 only:
- The OpenJDK 64bit build requires access to
- MSVCRT.DLL version 7.0.3790.0 or newer, which is
- usually supplied by the
- Platform SDK.
- If it is not available from the Platform SDK,
- set the
- ALT_MSVCRT_DLL_PATH
- variable to the location.
+ You can test that the build completed properly by using the build
+ to run the various demos that you will find in the
+ build/platform/j2sdk-image/demo
+ directory.
+

+ The provided regression tests can be run with the jtreg
+ utility from
+ the jtreg site.

+ Some of the
+ environment or make variables (just called variables in this
+ document) that can impact the build are:

-

- i586 only:
- The
- OpenJDK
- build requires access to
- MSVCR71.DLL version 7.10.3052.4 or newer which should be
- supplied by the
- Visual Studio product
- If the MSVCR71.DLL is not available from the
- Visual Studio product
- set the
- ALT_MSVCR71_DLL_PATH
- variable to the location.
-

- Once a machine is setup to build the
- OpenJDK,
- the steps to create the
- build are fairly simple.
- The various ALT settings can either be made into variables
- or can be supplied on the
- gmake
- command.
-

- Solaris:
- Note that ARCH_DATA_MODEL is really only needed on Solaris to
- indicate you want to built the 64-bit version.
- And before the Solaris 64-bit binaries can be used, they
- must be merged with the binaries from a separate 32-bit build.
- The merged binaries may then be used in either 32-bit or 64-bit mode, with
- the selection occurring at runtime
- with the -d32 or -d64 options.
-

- When the build is completed, you should see the generated
- binaries and associated files in the j2sdk-image
- directory in the output directory.
- The default output directory is
- build/platform,
- where platform is one of
-

-

solaris-sparc

-

solaris-sparcv9

-

solaris-i586

-

solaris-amd64

-

linux-i586

-

linux-amd64

-

windows-i586

-

windows-amd64

-

- In particular, the
- build/platform/j2sdk-image/bin
- directory should contain executables for the
- OpenJDK
- tools and utilities.
-

- You can test that the build completed properly by using the build
- to run the various demos that you will find in the
- build/platform/j2sdk-image/demo
- directory.
-

- The provided regression tests can be run with the jtreg
- utility from
- the jtreg site.
-

The ARCH_DATA_MODEL variable
- is used to specify whether the build is to generate 32-bit or 64-bit
- binaries.
- The Solaris build supports either 32-bit or 64-bit builds, but
- Windows and Linux will support only one, depending on the specific
- OS being used.
- Normally, setting this variable is only necessary on Solaris.
- Set ARCH_DATA_MODEL to 32 for generating 32-bit binaries,
- or to 64 for generating 64-bit binaries.
-

- The location of the binary plugs installation.
- See Binary Plugs for more information.
- You should always have a local copy of a
- recent Binary Plugs install image
- and set this variable to that location.
-

The location or locations for the Unix command utilities
+ (e.g. /usr/bin)

+

+

+

MILESTONE

- The location of the Microsoft Visual Studio .NET 2003
- tools 'bin' directory.
- The default is usually derived from
- ALT_COMPILER_PATH.
+ The milestone name for the build (e.g."beta").
+ The default value is "internal".

- The location of the
- Microsoft DirectX 9 SDK.
- The default will be to try and use the DirectX environment
- variable DXSDK_DIR,
- failing that, look in C:/DXSDK.
+ The build number for the build (e.g. "b27").
+ The default value is "b00".

The ARCH_DATA_MODEL variable
+ is used to specify whether the build is to generate 32-bit or 64-bit
+ binaries.
+ The Solaris build supports either 32-bit or 64-bit builds, but
+ Windows and Linux will support only one, depending on the specific
+ OS being used.
+ Normally, setting this variable is only necessary on Solaris.
+ Set ARCH_DATA_MODEL to 32 for generating 32-bit binaries,
+ or to 64 for generating 64-bit binaries.
+

- The location of the
- MSVCRT.DLL.
+ The location of the bootstrap JDK installation.
+ See Bootstrap JDK for more information.
+ You should always install your own local Bootstrap JDK and
+ always set ALT_BOOTDIR explicitly.

- i586 only:
- The location of the
- MSVCR71.DLL.
+ The location of the binary plugs installation.
+ See Binary Plugs for more information.
+ You should always have a local copy of a
+ recent Binary Plugs install image
+ and set this variable to that location.
+

+ The location of tools like the
+ zip and unzip
+ binaries, but might also contain the GNU make utility
+ (gmake).
+ So this area is a bit of a grab bag, especially on Windows.
+ The default value depends on the platform and
+ Unix Commands being used.
+ On Linux the default will be
+ $(ALT_JDK_DEVTOOLS_PATH)/linux/bin,
+ on Solaris
+ $(ALT_JDK_DEVTOOLS_PATH)/{sparc,i386}/bin,
+ on Windows with MKS
+ %SYSTEMDRIVE%/UTILS,
+ and on Windows with CYGWIN
+ /usr/bin.
+

+ An override for specifying where the
+ Unix command set are located.
+ The default location varies depending on the platform,
+ "%SYSTEMDRIVE%/MKSNT" or
+ $(ROOTDIR) on Windows with MKS, otherwise it's
+ "/bin" or /usr/bin.
+

+ These are useful in managing builds on multiple platforms.
+ The default network location for all of the import JDK images
+ for all platforms.
+ If ALT_JDK_IMPORT_PATH
+ is not set, this directory will be used and should contain
+ the following directories:
+ solaris-sparc,
+ solaris-i586,
+ solaris-sparcv9,
+ solaris-amd64,
+ linux-i586,
+ linux-amd64,
+ windows-i586,
+ and
+ windows-amd64.
+ Where each of these directories contain the import JDK image
+ for that platform.
+

+ These are useful in managing builds on multiple platforms.
+ The default network location for all of the binary plug images
+ for all platforms.
+ If ALT_BINARY_PLUGS_PATH
+ is not set, this directory will be used and should contain
+ the following directories:
+ solaris-sparc,
+ solaris-i586,
+ solaris-sparcv9,
+ solaris-amd64,
+ linux-i586,
+ linux-amd64,
+ windows-i586,
+ and
+ windows-amd64.
+ Where each of these directories contain the binary plugs image
+ for that platform.
+

- A build can fail for any number of reasons.
- Most failures
- are a result of trying to build in an environment in which all the
- pre-build requirements have not been met.
- The first step in
- troubleshooting a build failure is to recheck that you have satisfied
- all the pre-build requirements for your platform.
- Look for the check list of the platform you are building on in the
- Table of Contents.
-
-

- You can validate your build environment by using the sanity
- target.
- Any errors listed
- will stop the build from starting, and any warnings may result in
- a flawed product build.
- We strongly encourage you to evaluate every
- sanity check warning and fix it if required, before you proceed
- further with your build.
-
-

- Some of the more common problems with builds are briefly described
- below, with suggestions for remedies.
-
-

-

- Slow Builds:
-

-

- If your build machine seems to be overloaded from too many
- simultaneous C++ compiles, try setting the HOTSPOT_BUILD_JOBS
- variable to 1 (if you're using a multiple CPU
- machine, setting it to more than the the number of CPUs is probably
- not a good idea).
-

- Creating the javadocs can be very slow, if you are running
- javadoc, consider skipping that step.
-

- Faster hardware and more RAM always helps too.
- The VM build tends to be CPU intensive (many C++ compiles),
- and the rest of the JDK will often be disk intensive.
-

- These warnings can occur when the clock on the build machine is out of
- sync with the timestamps on the source files. Other errors, apparently
- unrelated but in fact caused by the clock skew, can occur along with
- the clock skew warnings. These secondary errors may tend to obscure the
- fact that the true root cause of the problem is an out-of-sync clock.
- For example, an out-of-sync clock has been known to cause an old
- version of javac to be used to compile some files, resulting in errors
- when the pre-1.4 compiler ran across the new assert keyword
- in the 1.4 source code.
-

- If you see these warnings, reset the clock on the build
- machine, run "gmake clobber" or delete the directory
- containing the build output, and restart the build from the beginning.
-

-

-

- Error message: Trouble writing out table to disk
-

-

- Increase the amount of swap space on your build machine.
-

-

-

- Error Message: libstdc++ not found:
-

- This is caused by a missing libstdc++.a library.
- This is installed as part of a specific package
- (e.g. libstdc++.so.devel.386).
- By default some 64bit Linux versions (e.g. Fedora)
- only install the 64bit version of the libstdc++ package.
- Various parts of the JDK build require a static
- link of the C++ runtime libraries to allow for maximum
- portability of the built images.
-

+ A build can fail for any number of reasons.
+ Most failures
+ are a result of trying to build in an environment in which all the
+ pre-build requirements have not been met.
+ The first step in
+ troubleshooting a build failure is to recheck that you have satisfied
+ all the pre-build requirements for your platform.
+ Look for the check list of the platform you are building on in the
+ Table of Contents.
+

+ You can validate your build environment by using the sanity
+ target.
+ Any errors listed
+ will stop the build from starting, and any warnings may result in
+ a flawed product build.
+ We strongly encourage you to evaluate every
+ sanity check warning and fix it if required, before you proceed
+ further with your build.
+

+ Some of the more common problems with builds are briefly described
+ below, with suggestions for remedies.
+

+

+ Slow Builds:
+

+ If your build machine seems to be overloaded from too many
+ simultaneous C++ compiles, try setting the HOTSPOT_BUILD_JOBS
+ variable to 1 (if you're using a multiple CPU
+ machine, setting it to more than the the number of CPUs is probably
+ not a good idea).
+

+ Creating the javadocs can be very slow, if you are running
+ javadoc, consider skipping that step.
+

+ Faster hardware and more RAM always helps too.
+ The VM build tends to be CPU intensive (many C++ compiles),
+ and the rest of the JDK will often be disk intensive.
+

+ These warnings can occur when the clock on the build machine is out of
+ sync with the timestamps on the source files. Other errors, apparently
+ unrelated but in fact caused by the clock skew, can occur along with
+ the clock skew warnings. These secondary errors may tend to obscure the
+ fact that the true root cause of the problem is an out-of-sync clock.
+ For example, an out-of-sync clock has been known to cause an old
+ version of javac to be used to compile some files, resulting in errors
+ when the pre-1.4 compiler ran across the new assert keyword
+ in the 1.4 source code.
+

+ If you see these warnings, reset the clock on the build
+ machine, run "gmake clobber" or delete the directory
+ containing the build output, and restart the build from the beginning.
+

+

+

+ Error message: Trouble writing out table to disk
+

+ Increase the amount of swap space on your build machine.
+

+

+

+ Error Message: libstdc++ not found:
+

+ This is caused by a missing libstdc++.a library.
+ This is installed as part of a specific package
+ (e.g. libstdc++.so.devel.386).
+ By default some 64bit Linux versions (e.g. Fedora)
+ only install the 64bit version of the libstdc++ package.
+ Various parts of the JDK build require a static
+ link of the C++ runtime libraries to allow for maximum
+ portability of the built images.
+