+ width=256>
|
+ width=256>
|
-- + +- This README file contains build instructions for the - OpenJDK. - Building the source code for the - OpenJDK - requires - a certain degree of technical expertise. + This README file contains build instructions for the + OpenJDK. + Building the source code for the + OpenJDK + requires + a certain degree of technical expertise. + + +
!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!
++ Some Headlines: ++
+- + The build is now a "
+configure && make" style build +- + Any GNU make 3.81 or newer should work +
+- + The build should scale, i.e. more processors should + cause the build to be done in less wall-clock time +
+- + Nested or recursive make invocations have been significantly + reduced, as has the total fork/exec or spawning + of sub processes during the build +
+- + Windows MKS usage is no longer supported +
+- + Windows Visual Studio
+vsvars*.batand +vcvars*.batfiles are run automatically +- + Ant is no longer used when building the OpenJDK +
+- + Use of ALT_* environment variables for configuring the + build is no longer supported +
+
- ++
- Introduction
+- Use of Mercurial
-- Minimum Build Environments
-- Specific Developer Build Environments + +
- Building
--
-- Fedora Linux
-- CentOS Linux
-- Debian GNU/Linux
-- Ubuntu Linux
-- OpenSUSE
-- Mandriva
-- OpenSolaris
-- Source Directory Structure -
--
- Managing the Source Drops
+- System Setup + +
+- Configure
+- Make
- Build Information +
- Testing
+
++
- Appendix A: Hints and Tips
--
- GNU Make (gmake)
-- Basic Linux System Setup
-- Basic Solaris System Setup
-- Basic Windows System Setup
-- Basic Mac OS X System Setup
-- Build Dependencies -
+-
-- Bootstrap JDK
-- Optional Import JDK
-- Ant 1.7.1
-- Certificate Authority File (cacert)
-- Compilers - -
-- Zip and Unzip
-- FreeType2 Fonts
-- Linux and Solaris: - -
-- Linux only: -
--
-- ALSA files
-- Windows only: -
--
-- Unix Command Tools (CYGWIN) or
-- Minimalist GNU for Windows (MinGW/MSYS)
-- DirectX 9.0 SDK
-- FAQ
+- Build Performance Tips
+- Troubleshooting
- Creating the Build
-- Testing the Build
-- Environment/Make Variables
-- Troubleshooting
-- The New Build
+- Appendix B: GNU Make Information
+- Appendix C: Build Environments
+ + +
The OpenJDK sources are maintained with the revision control system Mercurial. If you are new to Mercurial, please see the - Beginner Guides - or refer to the Mercurial Book. + + Beginner Guides + or refer to the + Mercurial Book. The first few chapters of the book provide an excellent overview of Mercurial, what it is and how it works.- +
@@ -130,578 +138,1631 @@ Developer Guide: Installing and Configuring Mercurial section for more information. -Getting the Source
To get the entire set of OpenJDK Mercurial repositories - use the script+ +get_source.shlocated in the root repository: + use the scriptget_source.shlocated in the + root repository:- - hg clone http://hg.openjdk.java.net/jdk8/jdk8 YourOpenJDK -+ Once you have all the repositories, keep in mind that each + repository is it's own independent repository. + You can also re-run
cd YourOpenJDK -
sh ./get_source.sh - ++ hg clone http://hg.openjdk.java.net/jdk8/jdk8 + YourOpenJDK ++
+ cd YourOpenJDK +
+ bash ./get_source.sh +./get_source.shanytime to + pull over all the latest changesets in all the repositories. + This set of nested repositories has been given the term + "forest" and there are various ways to apply the same +hgcommand to each of the repositories. + For example, the scriptmake/scripts/hgforest.sh+ can be used to repeat the samehg+ command on every repository, e.g. ++- Once you have all the repositories, the - script make/scripts/hgforest.sh - can be used to repeat the same hg - command on every repository in the forest, e.g. -+ cd YourOpenJDK +
+ bash ./make/scripts/hgforest.sh status +- - cd YourOpenJDK -+
sh ./make/scripts/hgforest.sh pull -u - -Repositories
+++ +The set of repositories and what they contain:
++ +
++ + + +Repository +Contains ++ ++ . (root) + ++ common configure and makefile logic + ++ ++ hotspot + ++ source code and make files for building + the OpenJDK Hotspot Virtual Machine + ++ ++ langtools + ++ source code for the OpenJDK javac and language tools + ++ ++ jdk + ++ source code and make files for building + the OpenJDK runtime libraries and misc files + ++ ++ jaxp + ++ source code for the OpenJDK JAXP functionality + ++ ++ jaxws + ++ source code for the OpenJDK JAX-WS functionality + ++ + ++ corba + ++ source code for the OpenJDK Corba functionality + +Repository Source Guidelines
++ There are some very basic guidelines: ++
- + Use of whitespace in source files + (.java, .c, .h, .cpp, and .hpp files) + is restricted. + No TABs, no trailing whitespace on lines, and files + should not terminate in more than one blank line. +
+- + Files with execute permissions should not be added + to the source repositories. +
+- + All generated files need to be kept isolated from + the files + maintained or managed by the source control system. + The standard area for generated files is the top level +
+build/directory. +- + The default build process should be to build the product + and nothing else, in one form, e.g. a product (optimized), + debug (non-optimized, -g plus assert logic), or + fastdebug (optimized, -g plus assert logic). +
+- + The .hgignore file in each repository + must exist and should + include ^build/, ^dist/ and + optionally any + nbproject/private directories. + It should NEVER include + anything in the + src/ or test/ + or any managed directory area of a repository. +
+- + Directory names and file names should never contain + blanks or + non-printing characters. +
+- + Generated source or binary files should NEVER be added to + the repository (that includes javah output). + There are some exceptions to this rule, in particular + with some of the generated configure scripts. +
+- + Files not needed for typical building + or testing of the repository + should not be added to the repository. +
+
- This file often describes specific requirements for what we call the - "minimum build environments" (MBE) for this - specific release of 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: -
-
- -
-- - - -Base OS and Architecture -OS -C/C++ Compiler -BOOT JDK -- -Linux X86 (32-bit) -Fedora 9 -gcc 4.3 -JDK 6u18 -- -Linux X64 (64-bit) -Fedora 9 -gcc 4.3 -JDK 6u18 -- -Solaris SPARC (32-bit) -Solaris 10 Update 6 -Sun Studio 12 Update 1 + patches -JDK 6u18 -- -Solaris SPARCV9 (64-bit) -Solaris 10 Update 6 -Sun Studio 12 Update 1 + patches -JDK 6u18 -- -Solaris X86 (32-bit) -Solaris 10 Update 6 -Sun Studio 12 Update 1 + patches -JDK 6u18 -- -Solaris X64 (64-bit) -Solaris 10 Update 6 -Sun Studio 12 Update 1 + patches -JDK 6u18 -- -Windows X86 (32-bit) -Windows XP -Microsoft Visual Studio C++ 2010 Professional Edition -JDK 6u18 -- -Windows X64 (64-bit) -Windows Server 2003 - Enterprise x64 Edition -Microsoft Visual Studio C++ 2010 Professional Edition -JDK 6u18 -- - -Mac OS X X64 (64-bit) -Mac OS X 10.7.3 "Lion" -XCode 4.1 or later -Java for OS X Lion Update 1 -- These same sources do indeed build on many more systems than the - above older generation systems, again the above is just a minimum. -
- Compilation problems with newer or different C/C++ compilers is a - common problem. - Similarly, compilation problems related to changes to the - /usr/include or system header files is also a - common problem with newer or unreleased OS versions. - Please report these types of problems as bugs so that they - can be dealt with accordingly. -
- We won't be listing all the possible environments, but - we will try to provide what information we have available to us. -- -
-- -Fedora 9
--
- After installing Fedora 9 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands as user - root: - --yum-builddep java-1.6.0-openjdk- -yum install gcc gcc-c++- - In addition, it's necessary to set a few environment variables for the build: - - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk-Fedora 10
-+ The very first step in building the OpenJDK is making sure the + system itself has everything it needs to do OpenJDK builds. + Once a system is setup, it generally doesn't need to be done again. +
+ Building the OpenJDK is now done with running a +configure+ script which will try and find and verify you have everything + you need, followed by running +make, e.g.- After installing Fedora 10 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands as user - root: - --yum-builddep java-1.6.0-openjdk- -yum install gcc gcc-c++- - In addition, it's necessary to set a few environment variables for the build: - - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk-Fedora 11
--
- After installing Fedora 11 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands as user - root: - --yum-builddep java-1.6.0-openjdk- -yum install gcc gcc-c++- - In addition, it's necessary to set a few environment variables for the build: - - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk+ ++ bash ./configure+
+ make all +
- After installing - CentOS 5.5 - you need to make sure you have - the following Development bundles installed: + Where possible the- -configurescript will attempt to located the + various components in the default locations or via component + specific variable settings. + When the normal defaults fail or components cannot be found, + additionalconfigureoptions may be necessary to helpconfigure+ find the necessary tools for the build, or you may need to + re-visit the setup of your system due to missing software + packages. +
+ NOTE: Theconfigurescript + file does not have + execute permissions and will need to be explicitly run with +bash, + see the source guidelines. + + +
+System Setup
+ Before even attempting to use a system to build the OpenJDK + there are some very basic system setups needed. + For all systems:--
-- Development Libraries
-- Development Tools
-- Java Development
-- X Software Development (Including XFree86-devel)
+- + Be sure the GNU make utility is version 3.81 or newer, + e.g. run "
+make -version" +- + Install a + Bootstrap JDK +
+
+ All OpenJDK builds require access to a previously released + JDK, this is often called a bootstrap JDK. + Currently, for this JDK release we require + JDK 7 Update 7 or newer. + The JDK 7 binaries can be downloaded from Oracle's + JDK 7 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 add itsbindirectory + to thePATHenvironment variable. + Ifconfigurehas any issues finding this JDK, you may + need to use theconfigureoption +--with-boot-jdk. +- + Insure that GNU make, the Bootstrap JDK, + and the compilers are all + in your PATH environment variable +
- Plus the following packages: -
---
+ And for specific systems: +- cups devel: Cups Development Package
-- alsa devel: Alsa Development Package
-- ant: Ant Package
-- Xi devel: libXi.so Development Package
-+ +
+ ++ + + +Linux +Solaris +Windows +Mac OS X ++ + ++ Install all the software development + packages needed including + alsa, + freetype, + cups, and + xrender. + +
+ See + specific system packages. ++ Install all the software development + packages needed including + Studio Compilers, + freetype, + cups, and + xrender. + +
+ See + specific system packages. ++ ++
+- + Install one of + CYGWIN or + MinGW/MSYS +
+- + Install + Visual Studio 2010 +
+- + Install the + Microsoft DirectX SDK +
++ Install + XCode 4.5.2 + and also install the "Command line tools" found under the + preferences pane "Downloads" + +Linux
++ With Linux, try and favor the system packages over + building your own + or getting packages from other areas. + Most Linux builds should be possible with the system's + available packages. ++ +
+ Note that some Linux systems have a habit of pre-populating + your environment variables for you, for exampleJAVA_HOME+ might get pre-defined for you to refer to the JDK installed on + your Linux system. + You will need to unsetJAVA_HOME. + It's a good idea to runenvand verify the + environment variables you are getting from the default system + settings make sense for building the OpenJDK. + +Solaris
+++ +Studio Compilers
++ At a minimum, the + + Studio 12 Update 1 Compilers + (containing version 5.10 of the C and C++ compilers) is required, + including specific patches. ++ ++ The Solaris SPARC patch list is: +
+
+- + 118683-05: SunOS 5.10: Patch for profiling libraries and assembler +
+- + 119963-21: SunOS 5.10: Shared library patch for C++ +
+- + 120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch +
+- + 128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler +
+- + 141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 +
+- + 141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler +
+- + 142371-01: Sun Studio 12.1 Update 1: Patch for dbx +
+- + 143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling +
+- + 143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 +
+- + 142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools +
++ The Solaris X86 patch list is: +
+
+- + 119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler +
+- + 119964-21: SunOS 5.10_x86: Shared library patch for C++_x86 +
+- + 120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch +
+- + 141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 backend +
+- + 128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler +
+- + 142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler +
+- + 142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools +
++ Place the
bindirectory inPATH. ++ The Oracle Solaris Studio Express compilers at: + + Oracle Solaris Studio Express Download site + are also an option, although these compilers have not + been extensively used yet. +
Windows
++ ++ +Windows Unix Toolkit
++ Building on Windows requires a Unix-like environment, notably a + Unix-like shell. + There are several such environments available of which + Cygwin and + MinGW/MSYS are + currently supported for + the OpenJDK build. One of the differences of these + systems from standard Windows tools is the way + they handle Windows path names, particularly path names which contain + spaces, backslashes as path separators and possibly drive letters. + Depending + on the use case and the specifics of each environment these path + problems can + be solved by a combination of quoting whole paths, translating + backslashes to + forward slashes, escaping backslashes with additional backslashes and + translating the path names to their + + "8.3" version. + ++ +CYGWIN
++ CYGWIN is an open source, Linux-like environment which tries to emulate + a complete POSIX layer on Windows. It tries to be smart about path names + and can usually handle all kinds of paths if they are correctly quoted + or escaped although internally it maps drive letters+ +<drive>:+ to a virtual directory/cygdrive/<drive>. ++ You can always use the
+cygpathutility to map pathnames with spaces + or the backslash character into theC:/style of pathname + (called 'mixed'), e.g.cygpath -s -m "path". ++ Note that the use of CYGWIN creates a unique problem with regards to + setting
+PATH. Normally on Windows + thePATHvariable contains directories + separated with the ";" character (Solaris and Linux use ":"). + With CYGWIN, it uses ":", but that means that paths like "C:/path" + cannot be placed in the CYGWIN version ofPATHand + instead CYGWIN uses something like/cygdrive/c/path+ which CYGWIN understands, but only CYGWIN understands. ++ The OpenJDK build requires CYGWIN version 1.7.16 or newer. + Information about CYGWIN can + be obtained from the CYGWIN website at + www.cygwin.com. +
++ By default CYGWIN doesn't install all the tools required for building + the OpenJDK. + Along with the default installation, you need to install + the following tools. +
++ Note that the CYGWIN software can conflict with other non-CYGWIN + software on your Windows system. + CYGWIN provides a + FAQ for + known issues and problems, of particular interest is the + section on + + BLODA (applications that interfere with CYGWIN). ++ +
++ + + +Binary Name +Category +Package +Description ++ +ar.exe +Devel +binutils ++ The GNU assembler, linker and binary utilities + ++ +make.exe +Devel +make ++ The GNU version of the 'make' utility built for CYGWIN + ++ +m4.exe +Interpreters +m4 ++ GNU implementation of the traditional Unix macro + processor + ++ +cpio.exe +Utils +cpio ++ A program to manage archives of files + ++ +gawk.exe +Utils +awk ++ Pattern-directed scanning and processing language + ++ +file.exe +Utils +file ++ Determines file type using 'magic' numbers + ++ +zip.exe +Archive +zip ++ Package and compress (archive) files + ++ +unzip.exe +Archive +unzip ++ Extract compressed files in a ZIP archive + ++ + +free.exe +System +procps ++ Display amount of free and used memory in the system + +MinGW/MSYS
++ MinGW ("Minimalist GNU for Windows") is a collection of free Windows + specific header files and import libraries combined with GNU toolsets that + allow one to produce native Windows programs that do not rely on any + 3rd-party C runtime DLLs. MSYS is a supplement to MinGW which allows building + applications and programs which rely on traditional UNIX tools to + be present. Among others this includes tools like+ +bash+ andmake. + See MinGW/MSYS + for more information. ++ Like Cygwin, MinGW/MSYS can handle different types of path formats. They + are internally converted to paths with forward slashes and drive letters +
+<drive>:replaced by a virtual + directory/<drive>. Additionally, MSYS automatically + detects binaries compiled for the MSYS environment and feeds them with the + internal, Unix-style path names. If native Windows applications are called + from within MSYS programs their path arguments are automatically converted + back to Windows style path names with drive letters and backslashes as + path separators. This may cause problems for Windows applications which + use forward slashes as parameter separator (e.g.cl /nologo /I) + because MSYS may wrongly + replace such parameters by drive letters. ++ In addition to the tools which will be installed + by default, you have + to manually install the +
msys-zipand +msys-unzippackages. + This can be easily done with the MinGW command line installer: +++mingw-get.exe install msys-zip+
+mingw-get.exe install msys-unzip+Visual Studio 2010 Compilers
+++ + ++ The 32-bit and 64-bit OpenJDK Windows build requires + Microsoft Visual Studio C++ 2010 (VS2010) Professional + Edition or Express compiler. + The compiler and other tools are expected to reside + in the location defined by the variable +
+VS100COMNTOOLSwhich + is set by the Microsoft Visual Studio installer. ++ Only the C++ part of VS2010 is needed. + Try to let the installation go to the default + install directory. + Always reboot your system after installing VS2010. + The system environment variable VS100COMNTOOLS + should be + set in your environment. +
++ Make sure that TMP and TEMP are also set + in the environment + and refer to Windows paths that exist, + like
+C:\temp, + not/tmp, not/cygdrive/c/temp, + and notC:/temp. +C:\tempis just an example, + it is assumed that this area is + private to the user, so by default + after installs you should + see a unique user path in these variables. +Mac OS X
++ Make sure you get the right XCode version. ++- The freetype 2.3 packages don't seem to be available, - but the freetype 2.3 sources can be downloaded, built, - and installed easily enough from - - the freetype site. - Build and install with something like: + + +
+Configure
- ./configure && make && sudo -u root make install + The basic invocation of the-configurescript + looks like: +++ This will create an output directory containing the + "configuration" and setup an area for the build result. + This directory typically looks like: +bash ./configure [options]+++build/linux-x64-normal-server-release+configurewill try to figure out what system you are running on + and where all necessary build components are. + If you have all prerequisites for building installed, + it should find everything. + If it fails to detect any component automatically, + it will exit and inform you about the problem. + When this happens, read more below in + theconfigureoptions. ++ Some examples: +
++ +
+ + ++ + + +Description +Configure Command Line ++ +Windows 32bit build with freetype specified ++ +bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32++ + +Debug 64bit Build ++ +bash ./configure --enable-debug --with-target-bits=64+Configure Options
++ Complete details on all the OpenJDK+configureoptions can + be seen with: +++ Usebash ./configure --help=short+-helpto see all theconfigureoptions + available. + + You can generate any number of different configurations, + e.g. debug, release, 32, 64, etc. + + Some of the more commonly usedconfigureoptions are: + ++ +
++ + + +OpenJDK Configure Option +Description ++ ++ --enable-debug+ set the debug level to fastdebug (this is a shorthand for + +--with-debug-level=fastdebug) ++ ++ --with-alsa=path+ select the location of the + Advanced Linux Sound Architecture (ALSA) + +
+ 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, + and it's highly recommended that you try and use + the package provided by the particular version of Linux that + you are using. ++ ++ --with-boot-jdk=path+ select the Bootstrap JDK + ++ ++ --with-boot-jdk-jvmargs="args"+ provide the JVM options to be used to run the + Bootstrap JDK + ++ ++ --with-cacerts=path+ select the path to the cacerts file. + +
+ 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. + By default an empty cacerts file is provided and that should be + fine for most JDK developers. ++ ++ --with-cups=path+ select the CUPS install location + +
+ The + Common UNIX Printing System (CUPS) Headers + are required for building the + OpenJDK on Solaris and Linux. + 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 the + directory/opt/sfw/cups. +
+ The CUPS header files can always be downloaded from + www.cups.org. ++ ++ --with-cups-include=path+ select the CUPS include directory location + ++ ++ --with-debug-level=level+ select the debug information level of release, + fastdebug, or slowdebug + ++ ++ --with-dev-kit=path+ select location of the compiler install or + developer install location + ++ ++ --with-dxsdk=path+ select location of the Windows Direct X SDK install + +
+ The Microsoft DirectX 9.0 SDK + header files and libraries + from the Summer 2004 edition + 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"). + Installation usually will set the environment variable +DXSDK_DIRto it's install location. ++ ++ --with-freetype=path+ select the freetype files to use. + +
+ Expecting the + freetype libraries under +lib/and the + headers underinclude/. +
+ Version 2.3 or newer of FreeType is required. + 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 the FreeType library and header files. +
+ You can always download latest FreeType version from the + FreeType website. +
+ Building the freetype 2 libraries from scratch is also possible, + however on Windows refer to the + + Windows FreeType DLL build instructions. +
+ Note that by default FreeType is built with byte code hinting + support disabled due to licensing restrictions. + In this case, text appearance and metrics are expected to + differ from Sun's official JDK build. + See + + the SourceForge FreeType2 Home Page + + for more information. ++ ++ --with-import-hotspot=path+ select the location to find hotspot + binaries from a previous build to avoid building + hotspot + ++ ++ --with-target-bits=arg+ select 32 or 64 bit build + ++ ++ --with-jvm-variants=variants+ select the JVM variants to build from, comma + separated list that can include: + server, client, kernel, zero and zeroshark + ++ ++ --with-memory-size=size+ select the RAM size that GNU make will think + this system has + ++ ++ --with-msvcr-dll=path+ select the +msvcr100.dll+ file to include in the + Windows builds (C/C++ runtime library for + Visual Studio). +
+ This is usually picked up automatically + from the redist + directories of Visual Studio 2010. ++ ++ --with-num-cores=cores+ select the number of cores to use (processor + count or CPU count) + ++ + ++ --with-x=path+ select the location of the X11 and xrender files. + +
+ The + XRender Extension Headers + are required for building the + OpenJDK on Solaris and Linux. +
+ The Linux header files are usually available from a "Xrender" + development package, it's recommended that you try and use + the package provided by the particular distribution of Linux that + you are using. +
+ The Solaris XRender header files is + included with the other X11 header files + in the package SFWxwinc + on new enough versions of + Solaris and will be installed in +/usr/X11/include/X11/extensions/Xrender.hor +/usr/openwin/share/include/X11/extensions/Xrender.h+- Mercurial packages could not be found easily, but a Google - search should find ones, and they usually include Python if - it's needed. -
-+ -Debian 5.0 (Lenny)
-+ + +
+Make
- After installing Debian 5 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands as user root: - -aptitude build-dep openjdk-6- -aptitude install openjdk-6-jdk libmotif-dev- - In addition, it's necessary to set a few environment variables for the build: - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk+ The basic invocation of themakeutility + looks like: +++ This will start the build to the output directory containing the + "configuration" that was created by themake all+configure+ script. Runmake helpfor more information on + the available targets. +
+ There are some of the make targets that + are of general interest: ++ +
+ + + +Make Target +Description ++ +empty +build everything but no images ++ ++ allbuild everything including images ++ ++ all-confbuild all configurations ++ ++ imagescreate complete j2sdk and j2re images ++ ++ installinstall the generated images locally, + typically in +/usr/local+ ++ cleanremove all files generated by make, + but not those generated by +configure+ ++ dist-cleanremove all files generated by both + and +configure(basically killing the configuration)+ + ++ helpgive some help on using +make, + including some interesting make targets
-- -Ubuntu 8.04
--
- After installing Ubuntu 8.04 - you need to install several build dependencies. - - First, you need to enable the universe repository in the - Software Sources application and reload the repository - information. The Software Sources application is available - under the System/Administration menu. - - The simplest way to install the build dependencies is to - execute the following commands: - --sudo aptitude build-dep openjdk-6- -sudo aptitude install openjdk-6-jdk- - In addition, it's necessary to set a few environment variables for the build: - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk-Ubuntu 8.10
--
- After installing Ubuntu 8.10 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands: - --sudo aptitude build-dep openjdk-6- -sudo aptitude install openjdk-6-jdk- - In addition, it's necessary to set a few environment variables for the build: - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk-Ubuntu 9.04
--
- After installing Ubuntu 9.04 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands: - --sudo aptitude build-dep openjdk-6- -sudo aptitude install openjdk-6-jdk- - In addition, it's necessary to set a few environment variables for the build: - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-openjdk-
-- -OpenSUSE 11.1
--
- After installing OpenSUSE 11.1 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands: - --sudo zypper source-install -d java-1_6_0-openjdk- -sudo zypper install make- - In addition, it is necessary to set a few environment variables for the build: - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk- - Finally, you need to unset theJAVA_HOMEenvironment variable: - -export -n JAVA_HOME-
-- -Mandriva Linux One 2009 Spring
-+ When the build is completed, you should see the generated + binaries and associated files in the
j2sdk-image+ directory in the output directory. + In particular, the +build/*/images/j2sdk-image/bin+ directory should contain executables for the + OpenJDK tools and utilities for that configuration. + The testing tooljtregwill be needed + and can be found at: + + the jtreg site. + The provided regression tests in the repositories + can be run with the command:- After installing Mandriva Linux One 2009 Spring - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands as user root: - --urpmi java-1.6.0-openjdk-devel ant make gcc gcc-c++ freetype-devel zip unzip libcups2-devel libxrender1-devel libalsa2-devel libstc++-static-devel libxtst6-devel libxi-devel- - In addition, it is necessary to set a few environment variables for the build: - -export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.6.0-openjdk-
-- + + + + + + + + + + + +OpenSolaris 2009.06
--
- After installing OpenSolaris 2009.06 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands: - -pfexec pkg install SUNWgmake SUNWj6dev SUNWant sunstudioexpress SUNWcups SUNWzip SUNWunzip SUNWxwhl SUNWxorg-headers SUNWaudh SUNWfreetype2- - In addition, it is necessary to set a few environment variables for the build: - -export LANG=C ALT_COMPILER_PATH=/opt/SunStudioExpress/bin/ ALT_CUPS_HEADERS_PATH=/usr/include/- - Finally, you need to make sure that the build process can find the Sun Studio compilers: - -export PATH=$PATH:/opt/SunStudioExpress/bin/+cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all
-+ + + +- 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. + +
FAQ
+-- + +Managing the Source Drops
-++ ++ Q: The
+configurefile looks horrible! + How are you going to edit it? +
+ A: Theconfigurefile is generated (think + "compiled") by the autoconf tools. The source code is + inconfigure.acvarious .m4 files in common/autoconf, + which are + much more readable. +- The repositories jaxp and jaxws actually - do not contain the sources for JAXP or JAX-WS. - These products have their own open source procedures at their - JAXP and - JAX-WS home pages. - The OpenJDK project does need access to these sources to build - a complete JDK image because JAXP and JAX-WS are part of the JDK. - The current process for delivery of the JAXP and JAX-WS sources - involves so called "source drop bundles" downloaded from a public - website. - There are many reasons for this current mechanism, and it is - understood that this is not ideal for the open source community. - It is possible this process could change in the future. + Q: + Why is the
-configurefile checked in, + if it is generated?
- NOTE: The - Complete OpenJDK Source Bundles will contain the JAXP and - JAX-WS sources. + A: + If it was not generated, every user would need to have the autoconf + tools installed, and re-generate theconfigurefile + as the first step. + Our goal is to minimize the work needed to be done by the user + to start building OpenJDK, and to minimize + the number of external dependencies required.Creation of New Source Drop Bundles
++ Q: + Do you require a specific version of autoconf for regenerating +
+ +configure? +
+ A: + Currently, no, but this will likely be the case when things have + settled down a bit more. (The reason for this is to avoid + large spurious changes inconfigure+ in commits that made small changes toconfigure.ac). ++ Q: + What are the files in
+ +common/makefiles/support/*for? + They look like gibberish. +
+ A: + They are a somewhat ugly hack to compensate for command line length + limitations on certain platforms (Windows, Solaris). + Due to a combination of limitations in make and the shell, + command lines containing too many files will not work properly. + These + helper files are part of an elaborate hack that will compress the + command line in the makefile and then uncompress it safely. + We're + not proud of it, but it does fix the problem. + If you have any better suggestions, we're all ears! :-) ++ Q: + I want to see the output of the commands that make runs, + like in the old build. How do I do that? +
+ A: + You specify theLOGvariable to make. There are + several log levels: +--+
+
- - The JAXP or JAX-WS team prepares a new zip bundle, - places a copy in a public download area on java.net, - sends us a link and a list of CRs (Change Request Numbers). - The older download bundles should not be deleted. - It is the responsibility of the JAXP and JAX-WS team to - place the proper GPL legal notices on the sources - and do any filtering or java re-packaging for the - OpenJDK instances of these classes. +
warn— Default and very quiet.- - The OpenJDK team copies this new bundle into shared - area (e.g. /java/devtools/share/jdk8-drops). - Older bundles are never deleted so we retain the history. +
info— Shows more progress information + than warn.- - The OpenJDK team edits the ant property file - jaxp/jaxp.properties or - jaxws/jaxws.properties to update the - base URL, the zip bundle name, and the MD5 checksum - of the zip bundle - (on Solaris: sum -c md5 bundlename) +
debug— Echos all command lines and + prints all macro calls for compilation definitions.- - OpenJDK team reviews and commits those changes with the - given CRs. +
-trace— Echos all $(shell) command + lines as well.Using Source Drop Bundles
++ Q: + When do I have to re-run
+ +configure? +
+ A: + Normally you will runconfigureonly once for creating a + configuration. + You need to re-run configuration only if you want to change any + configuration options, + or if you pull down changes to theconfigurescript. ++ Q: + I have added a new source file. Do I need to modify the makefiles? +
+ +
+ A: + Normally, no. If you want to create e.g. a new native + library, + you will need to modify the makefiles. But for normal file + additions or removals, no changes are needed. There are certan + exceptions for some native libraries where the source files are spread + over many directories which also contain courses for other + libraries. In these cases it was simply easier to create include lists + rather thane excludes. ++ Q: + When I run
+ +configure --help, I see many strange options, + like--dvidir. What is this? +
+ A: + Configure provides a slew of options by default, to all projects + that use autoconf. Most of them are not used in OpenJDK, + so you can safely ignore them. To list only OpenJDK specific features, + useconfigure --help=shortinstead. ++ Q: +
+ +configureprovides OpenJDK-specific features such as +--enable-jigsawor--with-builddeps-server+ that are not described in this document. What about those? +
+ A: + Try them out if you like! But be aware that most of these are + experimental features. + Many of them don't do anything at all at the moment; the option + is just a placeholder. Other depends on + pieces of code or infrastructure that is currently + not ready for prime time. ++ Q: + How will you make sure you don't break anything? +
+ +
+ A: + We have a script that compares the result of the new build system + with the result of the old. For most part, we aim for (and achieve) + byte-by-byte identical output. There are however technical issues + with e.g. native binaries, which might differ in a byte-by-byte + comparison, even + when building twice with the old build system. + For these, we compare relevant aspects + (e.g. the symbol table and file size). + Note that we still don't have 100% + equivalence, but we're close. ++ Q: + I noticed this thing X in the build that looks very broken by design. + Why don't you fix it? +
+ +
+ A: + Our goal is to produce a build output that is as close as + technically possible to the old build output. + If things were weird in the old build, + they will be weird in the new build. + Often, things were weird before due to obscurity, + but in the new build system the weird stuff comes up to the surface. + The plan is to attack these things at a later stage, + after the new build system is established. ++ Q: + The code in the new build system is not that well-structured. + Will you fix this? +
+ +
+ A: + Yes! The new build system has grown bit by bit as we converted + the old system. When all of the old build system is converted, + we can take a step back and clean up the structure of the new build + system. Some of this we plan to do before replacing the old build + system and some will need to wait until after. ++ Q: What is @GenerateNativeHeaders? +
+ +
+ A: + To speed up compilation, we added a flag to javac which makes it + do the job of javah as well, as a by-product; that is, generating + native .h header files. These files are only generated + if a class contains native methods. However, sometimes + a class contains no native method, + but still contains constants that native code needs to use. + The new GenerateNativeHeaders annotation tells javac to + force generation of a + header file in these cases. (We don't want to generate + native headers for all classes that contains constants + but no native methods, since + that would slow down the compilation process needlessly.) ++ Q: + Is anything able to use the results of the new build's default make target? +
+ +
+ A: + Yes, this is the minimal (or roughly minimal) + set of compiled output needed for a developer to actually + execute the newly built JDK. The idea is that in an incremental + development fashion, when doing a normal make, + you should only spend time recompiling what's changed + (making it purely incremental) and only do the work that's + needed to actually run and test your code. + The packaging stuff that is part of theimages+ target is not needed for a normal developer who wants to + test his new code. Even if it's quite fast, it's still unnecessary. + We're targeting sub-second incremental rebuilds! ;-) + (Or, well, at least single-digit seconds...) ++ Q: + I usually set a specific environment variable when building, + but I can't find the equivalent in the new build. + What should I do? +
+ +
+ A: + It might very well be that we have missed to add support for + an option that was actually used from outside the build system. + Email us and we will + add support for it! +Build Performance Tips
++ ++ +Building OpenJDK requires a lot of horsepower. + Some of the build tools can be adjusted to utilize more or less + of resources such as + parallel threads and memory. + The
+ +configurescript analyzes your system and selects reasonable + values for such options based on your hardware. + If you encounter resource problems, such as out of memory conditions, + you can modify the detected values with:+
+ +- +
+--with-num-cores+ — + number of cores in the build system, + e.g.--with-num-cores=8+- +
+--with-memory-size+ — memory (in MB) available in the build system, + e.g.--with-memory-size=1024+It might also be necessary to specify the JVM arguments passed + to the Bootstrap JDK, using e.g. +
+ + +--with-boot-jdk-jvmargs="-Xmx8G -enableassertions". + Doing this will override the default JVM arguments + passed to the Bootstrap JDK.One of the top goals of the new build system is to improve the + build performance and decrease the time needed to build. This will + soon also apply to the java compilation when the Smart Javac wrapper + is making its way into jdk8. It can be tried in the build-infra + repository already. You are likely to find that the new build system + is faster than the old one even without this feature.
+ +At the end of a successful execution of
+ +configure, + you will get a performance summary, + indicating how well the build will perform. Here you will + also get performance hints. + If you want to build fast, pay attention to those!Building with ccache
+ +A simple way to radically speed up compilation of native code + (typically hotspot and native libraries in JDK) is to install + ccache. This will cache and reuse prior compilation results, if the + source code is unchanged. However, ccache versions prior to 3.1.4 + does not work correctly with the precompiled headers used in + OpenJDK. So if your platform supports ccache at 3.1.4 or later, we + highly recommend installing it. This is currently only supported on + linux.
+ +Building on local disk
+ +If you are using network shares, e.g. via NFS, for your source code, + make sure the build directory is situated on local disk. + The performance + penalty is extremely high for building on a network share, + close to unusable.
+ +Building only one JVM
+ +The old build builds multiple JVMs on 32-bit systems (client and + server; and on Windows kernel as well). In the new build we have + changed this default to only build server when it's available. This + improves build times for those not interested in multiple JVMs. To + mimic the old behavior on platforms that support it, + use
+ +--with-jvm-variants=client,server.Selecting the number of cores to build on
+ +By default,
+ +configurewill analyze your machine and run the make + process in parallel with as many threads as you have cores. This + behavior can be overridden, either "permanently" (on aconfigure+ basis) using--with-num-cores=Nor for a single build + only (on a make basis), usingmake JOBS=N.If you want to make a slower build just this time, to save some CPU + power for other processes, you can run + e.g.
+ +make JOBS=2. This will force the makefiles + to only run 2 parallel processes, or evenmake JOBS=1+ which will disable parallelism.If you want to have it the other way round, namely having slow + builds default and override with fast if you're + impatient, you should call
+ +configurewith +--with-num-cores=2, making 2 the default. + If you want to run with more + cores, runmake JOBS=8Troubleshooting
++ +-Solving build problems
+--- The ant scripts that build jaxp and jaxws - will attempt to locate these zip bundles from the directory - in the environment variable - ALT_DROPS_DIR. - The checksums protect from getting the wrong, corrupted, or - improperly modified sources. - Once the sources are made available, the population will not - happen again unless a make clobber is requested - or the jaxp/drop/ or jaxws/drop/ - directory is explicitly deleted. -
-
- NOTE: The default Makefile and ant script behavior - is to NOT download these bundles from the public http site. - In general, doing downloads - during the build process is not advised, it creates too much - unpredictability in the build process. - However, you can use make ALLOW_DOWNLOADS=true to - tell the ant script that the download of the zip bundle is - acceptable. -- The recommended procedure for keeping a cache of these - source bundles would be to download them once, place them - in a directory outside the repositories, and then set - ALT_DROPS_DIR to refer - to that directory. - These drop bundles do change occasionally, so the newer - bundles may need to be added to this area from time to time. -
+ If the build fails (and it's not due to a compilation error in + a source file you've changed), the first thing you should do + is to re-run the build with more verbosity. + Do this by addingLOG=debugto your make command line. +
+ The build log (with both stdout and stderr intermingled, + basically the same as you see on your console) can be found as +build.login your build directory. +
+ You can ask for help on build problems with the new build system + on either the + + build-dev + or the + + build-infra-dev + mailing lists. Please include the relevant parts + of the build log. +
+ 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. + Scanning theconfigurelog is a good first step, making + sure that what it found makes sense for your system. + Look for strange error messages or any difficulties that +configurehad in finding things. +
+ Some of the more common problems with builds are briefly + described + below, with suggestions for remedies. ++
- + Corrupted Bundles on Windows: +
++ Some virus scanning software has been known to + corrupt the + downloading of zip bundles. + It may be necessary to disable the 'on access' or + 'real time' + virus scanning features to prevent this corruption. + This type of "real time" virus scanning can also + slow down the + build process significantly. + Temporarily disabling the feature, or excluding the build + output directory may be necessary to get correct and + faster builds. ++- + Slow Builds: +
++ If your build machine seems to be overloaded from too many + simultaneous C++ compiles, try setting the ++JOBS=1on themakecommand line. + Then try increasing the count slowly to an acceptable + level for your system. Also: ++ Creating the javadocs can be very slow, + if you are running + javadoc, consider skipping that step. ++
+ Faster CPUs, more RAM, and a faster DISK usually helps. + The VM build tends to be CPU intensive + (many C++ compiles), + and the rest of the JDK will often be disk intensive. +
+ Faster compiles are possible using a tool called + ccache. +- + File time issues: +
++ If you see warnings that refer to file time stamps, e.g. +++ Warning message:+ 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. ++ File `xxx' has modification time in + the future.+
+ Warning message:Clock skew detected. + Your build may + be incomplete.++ 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. + This could be caused by overloading the system and + it may be necessary to use: ++++ to reduce the load on the system. +make JOBS=1+- + 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 64-bit Linux versions (e.g. Fedora) + only install the 64-bit 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. ++- + Linux Error Message: +
+cannot restore segment prot after reloc++ This is probably an issue with SELinux (See + + http://en.wikipedia.org/wiki/SELinux). + Parts of the VM is built without the+-fPICfor + performance reasons. ++ To completely disable SELinux: +
+
+- +
$ su root- +
# system-config-securitylevel- +
In the window that appears, select the SELinux tab- +
Disable SELinux+ Alternatively, instead of completely disabling it you could + disable just this one check. +
+
+- Select System->Administration->SELinux Management
+- In the SELinux Management Tool which appears, + select "Boolean" from the menu on the left
+- Expand the "Memory Protection" group
+- Check the first item, labeled + "Allow all unconfined executables to use + libraries requiring text relocation ..."
+- + Windows Error Messages: +
+
+*** fatal error - couldn't allocate heap, ...+
+rm fails with "Directory not empty"+
+unzip fails with "cannot create ... Permission denied"+
+unzip fails with "cannot create ... Error 50"+
++ The CYGWIN software can conflict with other non-CYGWIN + software. See the CYGWIN FAQ section on + + BLODA (applications that interfere with CYGWIN). ++- + Windows Error Message:
+spawn failed++ Try rebooting the system, or there could be some kind of + issue with the disk or disk partition being used. + Sometimes it comes with a "Permission Denied" message. ++
- Building the OpenJDK - is done with a GNU make command line - and various - environment or make variable settings that direct the makefile 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 - make sanity && make --- 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). + GNU version of the utility command- -make+ (usually calledgmakeon Solaris). A few notes about using GNU make:
- You need GNU make version 3.81 or newer. -
-- - Place the location of the GNU make binary in the PATH. + If the GNU make utility on your systems is not + 3.81 or newer, + see "Building GNU make".
- - Linux: - The /usr/bin/make should be 3.81 or newer - and should work fine for you. - If this version is not 3.81 or newer, - see the "Building GNU make" section. + Place the location of the GNU make binary in the +
PATH.- Solaris: - Do NOT use /usr/bin/make on Solaris. + Do NOT use
/usr/bin/makeon Solaris. If your Solaris system has the software - from the Solaris Companion CD installed, - you should try and use gmake - which will be located in either the /opt/sfw/bin or - /usr/sfw/bin directory. - In more recent versions of Solaris GNU make might be found - at /usr/bin/gmake.
- NOTE: It is very likely that this gmake - could be 3.80, you need 3.81, in which case, - see the "Building GNU make" section. + from the Solaris Developer Companion CD installed, + you should try and usegmake+ which will be located in either the +/usr/bin,/opt/sfw/binor +/usr/sfw/bindirectory.- Windows: - Make sure you start your build inside a bash/sh/ksh shell and are - using a make.exe utility built for that environment.
+
- MKS builds need a native Windows version of GNU make - (see Building GNU make).
- Cygwin builds need - a make version which was specially compiled for the Cygwin environment - (see Building GNU make). WARNING: - the OpenJDK build with the make utility provided by Cygwin will not - work because it does not support drive letters in paths. Make sure that - your version of make will be found before the Cygwins default make by - setting an appropriate PATH environment variable or by removing - Cygwin's make after you built your own make version.
- MinGW/MSYS builds can use the default make which - comes with the environment. + Make sure you start your build inside a bash shell. +- + Mac OS X: + The XCode "command line tools" must be installed on your Mac.
@@ -714,1539 +1775,728 @@ ftp.gnu.org/pub/gnu/make/.
- -Building GNU make
+ +Building GNU make
- First step is to get the GNU make 3.81 (or newer) source from + First step is to get the GNU make 3.81 or newer source from ftp.gnu.org/pub/gnu/make/. - Building is a little different depending on the OS and unix toolset - on Windows: ---
-- - Linux: - ./configure && make -
-- - Solaris: - ./configure && gmake CC=gcc -
-- - Windows for CYGWIN:
-
- ./configure
- Add the line #define HAVE_CYGWIN_SHELL 1 to the end of config.h
- make
-
- This should produce make.exe in the current directory. -- - Windows for MKS:
-
- Edit config.h.W32 and uncomment the line #define HAVE_MKS_SHELL 1
- Set the environment for your native compiler (e.g. by calling:
- "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /Release /xp /x64) - nmake -f NMakefile.win32 -
- This should produce WinDebug/make.exe and WinRel/make.exe -
- If you get the error: NMAKE : fatal error U1045: spawn failed : Permission denied - you have to set the Read & execute permission for the file subproc.bat. -
- 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. -
-- --
-- - Install the - Bootstrap JDK, set - ALT_BOOTDIR. -
-- - Optional Import JDK, set - ALT_JDK_IMPORT_PATH. -
-- - Install or upgrade the FreeType development - package. -
-- - Install - Ant 1.7.1 or newer, - make sure it is in your PATH. -
-
- 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 64-bit 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. -
-- --
-- - Install the - Bootstrap JDK, set - ALT_BOOTDIR. -
-- - Optional Import JDK, set - ALT_JDK_IMPORT_PATH. -
-- - Install the - Sun Studio Compilers, set - ALT_COMPILER_PATH. -
-- - Install the - CUPS Include files, set - ALT_CUPS_HEADERS_PATH. -
-- - Install the XRender Include files. -
-- - Install - Ant 1.7.1 or newer, - make sure it is in your PATH. -
-
- i586 only: - The minimum recommended hardware for building the 32-bit 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 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, the shell and other Unix-tools required during the build - do 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 - "8.3" pathname without spaces for any path that contains spaces. - Unfortunately, this short pathname is somewhat dynamic (i.e. dependant on the - other files and directories inside a given directory) and can not be - algorithmicly calculated by only looking at a specific path name. -- -- The makefiles will try to translate any pathnames supplied - to it into the C:/ style automatically. -
-- Special care has to be taken if native Windows applications - like nmake or cl are called with file arguments processed - by Unix-tools like make or sh! -
-
- Building on Windows requires a Unix-like environment, notably a Unix-like shell. - There are several such environments available of which - MKS, - Cygwin and - MinGW/MSYS are currently supported for - the OpenJDK build. One of the differences of these three systems is the way - they handle Windows path names, particularly path names which contain - spaces, backslashes as path separators and possibly drive letters. Depending - on the use case and the specifics of each environment these path problems can - be solved by a combination of quoting whole paths, translating backslashes to - forward slashes, escaping backslashes with additional backslashes and - translating the path names to their - "8.3" version. -- -- As of this writing (MKS ver. 9.4, Cygwin ver. 1.7.9, MinGW/MSYS 1.0.17), - MKS builds are known to be the fastest Windows builds while MingGW/MSYS - builds are slightly slower (about 10%) than MKS builds and Cygwin builds - require nearly twice the time (about 180%) of MKS builds (e.g. on a - DualCore i7 notebook with 8GB of RAM, HDD and 64-bit Windows 7 operating system - the complete OpenJDK 8 product build takes about 49min with MKS, 54min with - MinGW/MSYS and 88min with Cygwin). -
-- Mixing tools from the different Unix emulation environments is not a good - idea and will probably not work! -
-- MKS: is a commercial product which includes - all the Unix utilities which are required to build the OpenJDK except GNU - make. In pre-OpenJDK times it was the only supported build environment on - Windows. The MKS tools support Windows paths with drive letters and - forward slashes as path separator. Paths in environment variables like (for - example) PATH are separated by semicolon ';'. -
-- Recent versions of MKS provide the dosname utility to convert paths - with spaces to short (8.3) path names,e .g. - dosname -s "path". -
-- If you are using the MKS environment, you need a native Windows version - of Gnu make which you can easily build yourself. -
-- Cygwin: - is an open source, Linux-like environment which tries to emulate - a complete POSIX layer on Windows. It tries to be smart about path names - and can usually handle all kinds of paths if they are correctly quoted - or escaped although internally it maps drive letters <drive>: - to a virtual directory /cygdrive/<drive>. -
-- You can always use the cygpath utility to map pathnames with spaces - or the backslash character into the C:/ style of pathname - (called 'mixed'), e.g. cygpath -s -m "path". -
-- Note that the 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 use ":"). - 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. -
-- If you are using the Cygwin environment, you need to - compile your own version - of GNU make because the default Cygwin make can not handle drive letters in paths. -
-- MinGW/MSYS: - MinGW ("Minimalist GNU for Windows") is a collection of free Windows - specific header files and import libraries combined with GNU toolsets that - allow one to produce native Windows programs that do not rely on any - 3rd-party C runtime DLLs. MSYS is a supplement to MinGW which allows building - applications and programs which rely on traditional UNIX tools to - be present. Among others this includes tools like bash and make. -
-- Like Cygwin, MinGW/MSYS can handle different types of path formats. They - are internally converted to paths with forward slashes and drive letters - <drive>: replaced by a virtual - directory /<drive>. Additionally, MSYS automatically - detects binaries compiled for the MSYS environment and feeds them with the - internal, Unix-style path names. If native Windows applications are called - from within MSYS programs their path arguments are automatically converted - back to Windows style path names with drive letters and backslashes as - path separators. This may cause problems for Windows applications which - use forward slashes as parameter separator (e.g. cl /nologo /I) - because MSYS may wrongly - replace such parameters by drive letters. -
-- If you are using the MinGW/MSYS system you can use the default make - version supplied by the environment. -
-
-- --
-- - Install one of the - CYGWIN, MinGW/MSYS or - MKS environments. -
-- - Install the - Bootstrap JDK, set - ALT_BOOTDIR. -
-- - Optional Import JDK, set - ALT_JDK_IMPORT_PATH. -
-- - Install the - Microsoft Visual Studio Compilers). -
-- - Setup all environment variables for compilers - (see compilers). -
-- - Install - Microsoft DirectX SDK. -
-- - Install - Ant 1.7.1 or newer, - make sure it is in your PATH and set - ANT_HOME. -
-
- X64 only: - The minimum recommended hardware for building - the Mac OS X version is any 64-bit capable Intel processor, at least 2 - GB of RAM, and approximately 3 GB of free disk space. You should also - have OS X Lion 10.7.3 installed. -- - -
-- --
-- - Install XCode 4.1 or newer. - If you install XCode 4.3 or newer, make sure you also install - "Command line tools" found under the preferences pane "Downloads". -
-- - Install "Java for OS X Lion Update 1", - set ALT_BOOTDIR to
-`/usr/libexec/java_home -v 1.6`-- - Optional Import JDK, set - ALT_JDK_IMPORT_PATH. -
-
- 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. - -- -Bootstrap JDK
-- 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. -
Optional Import JDK
-- 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. -- -Ant
-- All OpenJDK builds require access to least Ant 1.7.1. - The Ant tool is available from the - - Ant 1.7.1 archive download site. - You should always make sure ant is in your PATH, and - on Windows you may also need to set - ANT_HOME - to point to the location of - the Ant installation, this is the directory pathname - that contains a bin and lib. -- -
- WARNING: Ant versions used from IDE tools like NetBeans - or installed via system packages may not operate the same - as the one obtained from the Ant download bundles. - These system and IDE installers sometimes choose to change - the ant installation enough to cause differences. -Certificate Authority File (cacert)
-- 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. -- -Compilers
-- Linux gcc/binutils + Building is a little different depending on the OS but is + basically done with:- -- The GNU gcc compiler version should be 4.3 or newer. - The compiler used should be the default compiler installed - in /usr/bin. -- Solaris: Sun Studio -- At a minimum, the - - Sun Studio 12 Update 1 Compilers - (containing version 5.10 of the C and C++ compilers) is required, - including specific patches. -- Windows i586: Microsoft Visual Studio 2010 Compilers -- The Solaris SPARC patch list is: -
-
-- - 118683-05: SunOS 5.10: Patch for profiling libraries and assembler -
-- - 119963-21: SunOS 5.10: Shared library patch for C++ -
-- - 120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch -
-- - 128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler -
-- - 141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 -
-- - 141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler -
-- - 142371-01: Sun Studio 12.1 Update 1: Patch for dbx -
-- - 143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling -
-- - 143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 -
-- - 142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools -
-- The Solaris X86 patch list is: -
-
-- - 119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler -
-- - 119964-21: SunOS 5.10_x86: Shared library patch for C++_x86 -
-- - 120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch -
-- - 141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 backend -
-- - 128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler -
-- - 142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler -
-- - 142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools -
-- Set - ALT_COMPILER_PATH - to point to the location of - the compiler binaries, and place this location in the PATH. -
- The Oracle Solaris Studio Express compilers at: - - Oracle Solaris Studio Express Download site - are also an option, although these compilers have not - been extensively used yet. -
-- Windows x64: Microsoft Visual Studio 2010 Professional Compiler -- BEGIN WARNING: JDK 7 has transitioned to - use the newest VS2010 Microsoft compilers. - No other compilers are known to build the entire JDK, - including non-open portions. - Visual Studio 2010 Express compilers are now able to build all the - open source repositories, but this is 32 bit only. To build 64 bit - Windows binaries use the the 7.1 Windows SDK. - END WARNING. -
- The 32-bit OpenJDK Windows build requires - Microsoft Visual Studio C++ 2010 (VS2010) Professional - Edition or Express compiler. - The compiler and other tools are expected to reside - in the location defined by the variable - VS100COMNTOOLS which - is set by the Microsoft Visual Studio installer. -
- Once the compiler is installed, - it is recommended that you run VCVARS32.BAT - to set the compiler environment variables - INCLUDE, - LIB, and - PATH - prior to building the - OpenJDK. - The above environment variables MUST be set. - This compiler also contains the Windows SDK v 7.0a, - which is an update to the Windows 7 SDK. -
- WARNING: Make sure you check out the - CYGWIN link.exe WARNING. - The path /usr/bin must be after the path to the - Visual Studio product. -
- For X64, the set up is much the same as 32 bit - except that you run amd64\VCVARS64.BAT - to set the compiler environment variables. - Previously 64 bit builds had to use the 64 bit compiler in - an unbundled Windows SDK but this is no longer necessary if - you have VS2010 Professional. -- Windows x64: Microsoft Windows 7.1 SDK 64 bit compilers. - For a free alternative for 64 bit builds, use the 7.1 SDK. - Microsoft say that to set up your paths for this run -- c:\Program Files\Microsoft SDKs\Windows\v7.1\bin\setenv.cmd /x64. -- What was tested is just directly setting up LIB, INCLUDE, - PATH and based on the installation directories using the - DOS short name appropriate for the system, (you will - need to set them for yours, not just blindly copy this) eg : -- set VSINSTALLDIR=c:\PROGRA~2\MICROS~1.0 - set WindowsSdkDir=c:\PROGRA~1\MICROS~1\Windows\v7.1 - set PATH=%VSINSTALLDIR%\vc\bin\amd64;%VSINSTALLDIR%\Common7\IDE;%WindowsSdkDir%\bin;%PATH% - set INCLUDE=%VSINSTALLDIR%\vc\include;%WindowsSdkDir%\include - set LIB=%VSINSTALLDIR%\vc\lib\amd64;%WindowsSdkDir%\lib\x64 -- OS X Lion 10.7.3: LLVM GCC -- LLVM GCC is bundled with XCode. The version should be at least 4.2.1. +bash ./configure+
+makeZip and Unzip
-- 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. -- -Common UNIX Printing System (CUPS) Headers (Solaris & Linux)
-- 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. -
XRender Extension Headers (Solaris & Linux)
--- -- Solaris: - XRender header files are required for building the - OpenJDK on Solaris. - The XRender header file is included with the other X11 header files - in the package SFWxwinc on new enough versions of - Solaris and will be installed in - /usr/X11/include/X11/extensions/Xrender.h or - /usr/openwin/share/include/X11/extensions/Xrender.h -
- Linux: - XRender header files are required for building the - OpenJDK on Linux. - The Linux header files are usually available from a "Xrender" - development package, it's recommended that you try and use - the package provided by the particular distribution of Linux that - you are using. -
-FreeType 2
-- 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. -
- Building the freetype 2 libraries from scratch is also possible, - however on Windows refer to the - - Windows FreeType DLL build instructions. -
- Note that by default FreeType is built with byte code hinting - support disabled due to licensing restrictions. - In this case, text appearance and metrics are expected to - differ from Sun's official JDK build. - See - - the SourceForge FreeType2 Home Page - - for more information. -
Advanced Linux Sound Architecture (ALSA) (Linux only)
-- 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. -- There are no ALT* variables to change the assumed locations of ALSA, - the makefiles will expect to find the ALSA include files and library at: - /usr/include/alsa and /usr/lib/libasound.so. -- 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. -
- Installation: execute as root- As a last resort you can go to the - - Advanced Linux Sound Architecture Site and build it from - source. -
- [i586]:rpm -Uv --force alsa-lib-devel-0.9.1-rh61.i386.rpm
- [x64]:rpm -Uv --force alsa-lib-devel-0.9.8-amd64.x86_64.rpm
- Uninstallation:
- [i586]:rpm -ev alsa-lib-devel-0.9.1-rh61
- [x64]:rpm -ev alsa-lib-devel-0.9.8-amd64
- Make sure that you do not link to the static library - (libasound.a), - by verifying that the dynamic library (libasound.so) is - correctly installed in /usr/lib. -- Download driver and library - source tarballs from - ALSA's homepage. - As root, execute the following - commands (you may need to adapt the version number): -- Note that this is a minimum install that enables - building the JDK platform. To actually use ALSA sound drivers, more - steps are necessary as outlined in the documentation on ALSA's homepage. -- - $ tar xjf alsa-driver-0.9.1.tar.bz2 - $ cd alsa-driver-0.9.1 - $ ./configure - $ make install - $ cd .. - $ tar xjf alsa-lib-0.9.1.tar.bz2 - $ cd alsa-lib-0.9.1 - $ ./configure - $ make install - -- Should one of the above steps fail, refer to the documentation on - ALSA's home page. -- ALSA can be uninstalled by executing make uninstall first in - the alsa-lib-0.9.1 directory and then in - alsa-driver-0.9.1. -
- Unix Command Tools (CYGWIN) -- + + + +- The OpenJDK requires access to a set of unix command tools - on Windows which can be supplied by - CYGWIN. -- Minimalist GNU for Windows (MinGW/MSYS) -- The OpenJDK build requires CYGWIN version 1.5.12 or newer. - Information about CYGWIN can - be obtained from the CYGWIN website at - www.cygwin.com. -
- By default CYGWIN doesn't install all the tools required for building - the OpenJDK. - Along with the default installation, you need to install - the following tools. -
--- -
-- - - -Binary Name -Category -Package -Description -- -ar.exe -Devel -binutils -The GNU assembler, linker and binary - utilities -- -make.exe -Devel -make -The GNU version of the 'make' utility built for CYGWIN. -
- NOTE: the Cygwin make can not be used to build the - OpenJDK. You only need it to build your own version of make - (see the GNU make section)- -m4.exe -Interpreters -m4 -GNU implementation of the traditional Unix macro - processor -- -cpio.exe -Utils -cpio -A program to manage archives of files -- -gawk.exe -Utils -awk -Pattern-directed scanning and processing language -- -file.exe -Utils -file -Determines file type using 'magic' numbers -- -zip.exe -Archive -zip -Package and compress (archive) files -- -unzip.exe -Archive -unzip -Extract compressed files in a ZIP archive -- - -free.exe -System -procps -Display amount of free and used memory in the system -- Note that the CYGWIN software can conflict with other non-CYGWIN - software on your Windows system. - CYGWIN provides a - FAQ for - known issues and problems, of particular interest is the - section on - - BLODA (applications that interfere with CYGWIN). -
- WARNING: - Be very careful with link.exe, it will conflict - with the Visual Studio version. You need the Visual Studio - version of link.exe, not the CYGWIN one. - So it's important that the Visual Studio paths in PATH preceed - the CYGWIN path /usr/bin. -
- Alternatively, the set of unix command tools for the OpenJDK build on - Windows can be supplied by - MinGW/MSYS. -- Microsoft DirectX 9.0 SDK header files and libraries -- In addition to the tools which will be installed by default, you have - to manually install the msys-zip and msys-unzip packages. - This can be easily done with the MinGW command line installer:
-
-
- mingw-get.exe install msys-zip
- mingw-get.exe install msys-unzip
- -- 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. -- MSVCR100.DLL -- The OpenJDK build requires access to a redistributable - MSVCR100.DLL. - This is usually picked up automatically from the redist - directories of Visual Studio 2010. - If this cannot be found set the - ALT_MSVCRNN_DLL_PATH - variable to the location of this file. ---
- 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. -- --
-- Use the sanity rule to double check all the ALT settings: -
-- - gmake - sanity - [ARCH_DATA_MODEL=32 or 64] - [other "ALT_" overrides] - --- Start the build with the command: -
-- - gmake - [ARCH_DATA_MODEL=32 or 64] - [ALT_OUTPUTDIR=output_directory] - [other "ALT_" overrides] - --- 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 -- --- In particular, the - build/platform/j2sdk-image/bin - directory should contain executables for the - OpenJDK tools and utilities. --
-- solaris-sparc
-- solaris-sparcv9
-- solaris-i586
-- solaris-amd64
-- linux-i586
-- linux-amd64
-- windows-i586
-- windows-amd64
-- 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: +
-- + +-
-- PATH
-- Typically you want to set the PATH to include: -
--
-- The location of the GNU make binary
-- The location of the Bootstrap JDK java - (see Bootstrap JDK)
-- The location of the C/C++ compilers - (see compilers)
-- The location or locations for the Unix command utilities - (e.g. /usr/bin)
-- MILESTONE
-- - The milestone name for the build (e.g."beta"). - The default value is "internal". -
-- BUILD_NUMBER
-- - The build number for the build (e.g. "b27"). - The default value is "b00". -
-- ARCH_DATA_MODEL
-- 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. -
-- ALT_BOOTDIR
-- - 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. -
-- ALT_JDK_IMPORT_PATH
-- - The location of a previously built JDK installation. - See Optional Import JDK for more information. -
-- ALT_OUTPUTDIR
-- - An override for specifying the (absolute) path of where the - build output is to go. - The default output directory will be build/platform. -
-- ALT_COMPILER_PATH
-- - The location of the C/C++ compiler. - The default varies depending on the platform. -
-- ALT_CACERTS_FILE
-- - The location of the cacerts file. - The default will refer to - jdk/src/share/lib/security/cacerts. -
-- ALT_CUPS_HEADERS_PATH
-- - The location of the CUPS header files. - See CUPS information for more information. - If this path does not exist the fallback path is - /usr/include. -
-- ALT_FREETYPE_LIB_PATH
-- - The location of the FreeType shared library. - See FreeType information for details. -
-- ALT_FREETYPE_HEADERS_PATH
-- - The location of the FreeType header files. - See FreeType information for details. -
-- ALT_JDK_DEVTOOLS_PATH
-- - The default root location of the devtools. - The default value is - $(ALT_SLASH_JAVA)/devtools. -
-- ALT_DEVTOOLS_PATH
-- - 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, - and on Windows with CYGWIN - /usr/bin. -
-- ALT_DROPS_DIR
-- - The location of any source drop bundles - (see Managing the Source Drops). - The default will be - $(ALT_JDK_DEVTOOLS_PATH)/share/jdk8-drops. -
-- ALT_UNIXCCS_PATH
-- - Solaris only: - An override for specifying where the Unix CCS - command set are located. - The default location is /usr/ccs/bin -
-- ALT_SLASH_JAVA
-- - The default root location for many of the ALT path locations - of the following ALT variables. - The default value is - "/java" on Solaris and Linux, - "J:" on Windows. -
-- ALT_BUILD_JDK_IMPORT_PATH
-- - 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. -
-- ALT_OPENWIN_HOME
-- - The top-level directory of the libraries and include files for the platform's - graphical programming environment. The default location is platform specific. - For example, on Linux it defaults to /usr/X11R6/. -
-- Windows specific:
-- -
--
-- ALT_WINDOWSSDKDIR
-- - The location of the - Microsoft Windows SDK where some tools will be - located. - The default is whatever WINDOWSSDKDIR is set to - (or WindowsSdkDir) or the path -
-
- c:\Program Files\Microsoft SDKs\Windows\v7.0a -- ALT_DXSDK_PATH
-- - 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. -
-- ALT_MSVCRNN_DLL_PATH
-- - The location of the - MSVCR100.DLL. -
-- Cross-Compilation Support:
-- -
-
-- CROSS_COMPILE_ARCH
-- - Set to the target architecture of a cross-compilation build. If set, this - variable is used to signify that we are cross-compiling. The expectation - is that ALT_COMPILER_PATH is set - to point to the cross-compiler and that any cross-compilation specific flags - are passed using EXTRA_CFLAGS. - The ALT_OPENWIN_HOME variable should - also be set to point to the graphical header files (e.g. X11) provided with - the cross-compiler. - When cross-compiling we skip execution of any demos etc that may be built, and - also skip binary-file verification. -
-- EXTRA_CFLAGS
-- - Used to pass cross-compilation options to the cross-compiler. - These are added to the CFLAGS and CXXFLAGS variables. -
-- USE_ONLY_BOOTDIR_TOOLS
-- - Used primarily for cross-compilation builds (and always set in that case) - this variable indicates that tools from the boot JDK should be used during - the build process, not the tools (javac, javah, jar) - just built (which can't execute on the build host). -
-- HOST_CC
-- - The location of the C compiler to generate programs to run on the build host. - Some parts of the build generate programs that are then compiled and executed - to produce other parts of the build. Normally the primary C compiler is used - to do this, but when cross-compiling that would be the cross-compiler and the - resulting program could not be executed. - On Linux this defaults to /usr/bin/gcc; on other platforms it must be - set explicitly. -
-- Specialized Build Options:
-- - Some build variables exist to support specialized build environments and/or specialized - build products. Their use is only supported in those contexts: -
--
-- BUILD_CLIENT_ONLY
-- - Indicates this build will only contain the Hotspot client VM. In addition to - controlling the Hotspot build target, it ensures that we don't try to copy - any server VM files/directories, and defines a default jvm.cfg file - suitable for a client-only environment. Using this in a 64-bit build will - generate a sanity warning as 64-bit client builds are not directly supported. -
-- BUILD_HEADLESS_ONLY
-- - Used when the build environment has no graphical capabilities at all. This - excludes building anything that requires graphical libraries to be available. -
-- JAVASE_EMBEDDED
-- - Used to indicate this is a build of the Oracle Java SE Embedded product. - This will enable the directives included in the SE-Embedded specific build - files. -
-- LIBZIP_CAN_USE_MMAP
-- - If set to false, disables the use of mmap by the zip utility. Otherwise, - mmap will be used. -
-- COMPRESS_JARS
-- - If set to true, causes certain jar files that would otherwise be built without - compression, to use compression. -
-
+ This file often describes specific requirements for what we + call the + "minimum build environments" (MBE) for this + specific release of the JDK. + What is listed below is what the Oracle Release + Engineering Team will use to build the Oracle JDK product. + Building with the MBE will hopefully generate the most compatible + bits that install on, and run correctly on, the most variations + of the same base OS and hardware architecture. + In some cases, these represent what is often called the + least common denominator, but each Operating System has different + aspects to it. ++ + ++ In all cases, the Bootstrap JDK version minimum is critical, + we cannot guarantee builds will work with older Bootstrap JDK's. + Also in all cases, more RAM and more processors is better, + the minimums listed below are simply recommendations. +
+ With Solaris and Mac OS X, the version listed below is the + oldest release we can guarantee builds and works, and the + specific version of the compilers used could be critical. +
+ With Windows the critical aspect is the Visual Studio compiler + used, which due to it's runtime, generally dictates what Windows + systems can do the builds and where the resulting bits can + be used.
+ NOTE: We expect a change here off these older Windows OS releases + and to a 'less older' one, probably Windows 2008R2 X64. ++ With Linux, it was just a matter of picking a + stable distribution that is a good representative for Linux + in general.
+ NOTE: We expect a change here from Fedora 9 to something else, + but it has not been completely determined yet, possibly + Ubuntu 12.04 X64, unbiased community feedback would be welcome on + what a good choice would be here. ++ It is understood that most developers will NOT be using these + specific versions, and in fact creating these specific versions + may be difficult due to the age of some of this software. + It is expected that developers are more often using the more + recent releases and distributions of these operating systems. +
+ Compilation problems with newer or different C/C++ compilers is a + common problem. + Similarly, compilation problems related to changes to the +
+/usr/includeor system header files is also a + common problem with older, newer, or unreleased OS versions. + Please report these types of problems as bugs so that they + can be dealt with accordingly. ++ +
++ + + +Base OS and Architecture +OS +C/C++ Compiler +Bootstrap JDK +Processors +RAM Minimum +DISK Needs ++ +Linux X86 (32-bit) and X64 (64-bit) +Fedora 9 +gcc 4.3 +JDK 7u7 +2 or more +1 GB +6 GB ++ +Solaris SPARC (32-bit) and SPARCV9 (64-bit) +Solaris 10 Update 6 +Studio 12 Update 1 + patches +JDK 7u7 +4 or more +4 GB +8 GB ++ +Solaris X86 (32-bit) and X64 (64-bit) +Solaris 10 Update 6 +Studio 12 Update 1 + patches +JDK 7u7 +4 or more +4 GB +8 GB ++ +Windows X86 (32-bit) +Windows XP +Microsoft Visual Studio C++ 2010 Professional Edition +JDK 7u7 +2 or more +2 GB +6 GB ++ +Windows X64 (64-bit) +Windows Server 2003 - Enterprise x64 Edition +Microsoft Visual Studio C++ 2010 Professional Edition +JDK 7u7 +2 or more +2 GB +6 GB ++ + +Mac OS X X64 (64-bit) +Mac OS X 10.7 "Lion" +XCode 4.5.2 or newer +JDK 7u7 +2 or more +4 GB +6 GB +
+ We won't be listing all the possible environments, but + we will try to provide what information we have available to us. ++ + + + + + + ++ NOTE: The community can help out by updating + this part of the document. + + +
Fedora
++ After installing the latest + Fedora + you need to install several build dependencies. + The simplest way to do it is to execute the + following commands as user+ + +root: +++yum-builddep java-1.7.0-openjdk+
+yum install gcc gcc-c++++ In addition, it's necessary to set a few environment + variables for the build: +
++export LANG=C+
+export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}"+CentOS 5.5
++ After installing + CentOS 5.5 + you need to make sure you have + the following Development bundles installed: ++ ++++
+- Development Libraries
+- Development Tools
+- Java Development
+- X Software Development (Including XFree86-devel)
++ Plus the following packages: +
+++
+- cups devel: Cups Development Package
+- alsa devel: Alsa Development Package
+- Xi devel: libXi.so Development Package
++ The freetype 2.3 packages don't seem to be available, + but the freetype 2.3 sources can be downloaded, built, + and installed easily enough from + + the freetype site. + Build and install with something like: +
++bash ./configure+
+make+
+sudo -u root make install++ Mercurial packages could not be found easily, but a Google + search should find ones, and they usually include Python if + it's needed. +
Debian 5.0 (Lenny)
++ After installing Debian 5 + you need to install several build dependencies. + The simplest way to install the build dependencies is to + execute the following commands as user+ +root: +++aptitude build-dep openjdk-7+
+aptitude install openjdk-7-jdk libmotif-dev++ In addition, it's necessary to set a few environment + variables for the build: +
++export LANG=C+
+export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"+Ubuntu 12.04
++ After installing Ubuntu 12.04 + you need to install several build dependencies. The simplest + way to do it is to execute the following commands: ++ +++sudo aptitude build-dep openjdk-7+
+sudo aptitude install openjdk-7-jdk++ In addition, it's necessary to set a few environment + variables for the build: +
++export LANG=C+
+export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"+OpenSUSE 11.1
++ After installing OpenSUSE 11.1 + you need to install several build dependencies. + The simplest way to install the build dependencies is to + execute the following commands: ++ +++sudo zypper source-install -d java-1_7_0-openjdk+
+sudo zypper install make++ In addition, it is necessary to set a few environment + variables for the build: +
++export LANG=C+
+export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}"++ Finally, you need to unset the
JAVA_HOME+ environment variable: +++export -n JAVA_HOME+Mandriva Linux One 2009 Spring
++ After installing Mandriva + Linux One 2009 Spring + you need to install several build dependencies. + The simplest way to install the build dependencies is to + execute the following commands as user+ +root: +++urpmi java-1.7.0-openjdk-devel make gcc gcc-c++ + freetype-devel zip unzip libcups2-devel libxrender1-devel + libalsa2-devel libstc++-static-devel libxtst6-devel + libxi-devel++ In addition, it is necessary to set a few environment + variables for the build: +
++export LANG=C+
+export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}"+OpenSolaris 2009.06
++ After installing OpenSolaris 2009.06 + you need to install several build dependencies. + The simplest way to install the build dependencies is to + execute the following commands: ++ +++pfexec pkg install SUNWgmake SUNWj7dev + sunstudioexpress SUNWcups SUNWzip SUNWunzip SUNWxwhl + SUNWxorg-headers SUNWaudh SUNWfreetype2++ In addition, it is necessary to set a few environment + variables for the build: +
++export LANG=C+
+export PATH="/opt/SunStudioExpress/bin:${PATH}"+
- You don't have to use all these hints and tips, and in fact people do actually - build with systems that contradict these, but they might prove to be - helpful to some. -- +-
-- - If make sanity does not work, find out why, fix that - before going any further. Or at least understand what the - complaints are from it. -
-- - JDK: Keep in mind that you are building a JDK, but you need - a JDK (BOOTDIR JDK) to build this JDK. -
-- - Ant: The ant utility is a java application and besides having - ant available to you, it's important that ant finds the right - java to run with. Make sure you can type ant -version - and get clean results with no error messages. -
-- - Linux: Try and favor the system packages over building your own - or getting packages from other areas. - Most Linux builds should be possible with the system's - available packages. -
-- - Solaris: Typically you will need to get compilers on your systems - and occasionally GNU make 3.81 if a gmake binary is not available. - The gmake binary might not be 3.81, be careful. -
-- - Windows VS2010: -
--
-- - Only the C++ part of VS2010 is needed. - Try to let the installation go to the default install directory. - Always reboot your system after installing VS2010. - The system environment variable VS100COMNTOOLS should be - set in your environment. -
-- - Make sure that TMP and TEMP are also set in the environment - and refer to Windows paths that exist, like C:\temp, - not /tmp, not /cygdrive/c/temp, and not C:/temp. - C:\temp is just an example, it is assumed that this area is - private to the user, so by default after installs you should - see a unique user path in these variables. -
-- - You need to use vsvars32.bat or vsvars64.bat to get the - PATH, INCLUDE, LIB, LIBPATH, and WINDOWSSDKDIR - variables set in your shell environment. - These bat files are not easy to use from a shell environment. - However, there is a script placed in the root jdk8 repository called - vsvars.sh that can help, it should only be done once in a shell - that will be doing the build, e.g.
-
- sh ./make/scripts/vsvars.sh -v10 > settings
- eval `cat settings`
- Or just eval `sh ./make/scripts/vsvars.sh -v10`. -- - Windows: PATH order is critical, see the - paths section for more information. -
-- - Windows 64bit builds: Use ARCH_DATA_MODEL=64. -
-
End of OpenJDK README-builds.html document.
Please come again!
- 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. -
-
-- - Corrupted Bundles on Windows: -
-- Some virus scanning software has been known to corrupt the - downloading of zip bundles. - It may be necessary to disable the 'on access' or 'real time' - virus scanning features to prevent this corruption. - This type of "real time" virus scanning can also slow down the - build process significantly. - Temporarily disabling the feature, or excluding the build - output directory may be necessary to get correct and faster builds. --- - 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. -
- Faster compiles are possible using a tool called - ccache. -
- - File time issues: -
-- If you see warnings that refer to file time stamps, e.g. --- Warning message: File `xxx' has modification time in - the future. -- 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. -
- Warning message: Clock skew detected. Your build may - be incomplete. -- 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 64-bit Linux versions (e.g. Fedora) - only install the 64-bit 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. --- - Error Message: cannot restore segment prot after reloc -
-- This is probably an issue with SELinux (See - - http://en.wikipedia.org/wiki/SELinux). - Parts of the VM is built without the -fPIC for - performance reasons. --- To completely disable SELinux: -
-
-- $ su root
-- # system-config-securitylevel
-- In the window that appears, select the SELinux tab
-- Disable SELinux
-- Alternatively, instead of completely disabling it you could - disable just this one check. -
-
-- Select System->Administration->SELinux Management
-- In the SELinux Management Tool which appears, - select "Boolean" from the menu on the left
-- Expand the "Memory Protection" group
-- Check the first item, labeled - "Allow all unconfined executables to use libraries requiring text relocation ..."
-- - Windows Error Messages:
-
- *** fatal error - couldn't allocate heap, ...
- rm fails with "Directory not empty"
- unzip fails with "cannot create ... Permission denied"
- unzip fails with "cannot create ... Error 50"
-- The CYGWIN software can conflict with other non-CYGWIN - software. See the CYGWIN FAQ section on - - BLODA (applications that interfere with CYGWIN). --- - Windows Error Message: spawn failed -
-- Try rebooting the system, or there could be some kind of - issue with the disk or disk partition being used. - Sometimes it comes with a "Permission Denied" message. --
- The - Build Infrastructure project is working on a new - build. For information on how to try it out, please see the - - Build Infra User Guide --