diff options
Diffstat (limited to 'README-builds.html')
| -rw-r--r-- | README-builds.html | 2495 |
1 files changed, 0 insertions, 2495 deletions
diff --git a/README-builds.html b/README-builds.html deleted file mode 100644 index 14796a2..0000000 --- a/README-builds.html +++ /dev/null @@ -1,2495 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> - <head> - <title>OpenJDK Build README</title> - </head> - <body style="background-color:aquamarine"> - - <!-- ====================================================== --> - <table width="100%"> - <tr> - <td align="center"> - <img alt="OpenJDK" - src="http://openjdk.java.net/images/openjdk.png" - width=256> - </td> - </tr> - <tr> - <td align=center> - <h1>OpenJDK Build README</h1> - </td> - </tr> - </table> - - <!-- ====================================================== --> - <hr> - <h2><a name="introduction">Introduction</a></h2> - <blockquote> - This README file contains build instructions for the - <a href="http://openjdk.java.net" target="_blank">OpenJDK</a>. - Building the source code for the - OpenJDK - requires - a certain degree of technical expertise. - - <!-- ====================================================== --> - <h3>!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!</h3> - <blockquote> - Some Headlines: - <ul> - <li> - The build is now a "<code>configure && make</code>" style build - </li> - <li> - Any GNU make 3.81 or newer should work - </li> - <li> - The build should scale, i.e. more processors should - cause the build to be done in less wall-clock time - </li> - <li> - Nested or recursive make invocations have been significantly - reduced, as has the total fork/exec or spawning - of sub processes during the build - </li> - <li> - Windows MKS usage is no longer supported - </li> - <li> - Windows Visual Studio <code>vsvars*.bat</code> and - <code>vcvars*.bat</code> files are run automatically - </li> - <li> - Ant is no longer used when building the OpenJDK - </li> - <li> - Use of ALT_* environment variables for configuring the - build is no longer supported - </li> - </ul> - </blockquote> - </blockquote> - - <!-- ====================================================== --> - <hr> - <h2><a name="contents">Contents</a></h2> - <blockquote> - <ul> - <li><a href="#introduction">Introduction</a></li> - - <li><a href="#hg">Use of Mercurial</a> - <ul> - <li><a href="#get_source">Getting the Source</a></li> - <li><a href="#repositories">Repositories</a></li> - </ul> - </li> - - <li><a href="#building">Building</a> - <ul> - <li><a href="#setup">System Setup</a> - <ul> - <li><a href="#linux">Linux</a></li> - <li><a href="#solaris">Solaris</a></li> - <li><a href="#macosx">Mac OS X</a></li> - <li><a href="#windows">Windows</a></li> - </ul> - </li> - <li><a href="#configure">Configure</a></li> - <li><a href="#make">Make</a></li> - </ul> - </li> - <li><a href="#testing">Testing</a></li> - </ul> - <hr> - <ul> - <li><a href="#hints">Appendix A: Hints and Tips</a> - <ul> - <li><a href="#faq">FAQ</a></li> - <li><a href="#performance">Build Performance Tips</a></li> - <li><a href="#troubleshooting">Troubleshooting</a></li> - </ul> - </li> - <li><a href="#gmake">Appendix B: GNU Make Information</a></li> - <li><a href="#buildenvironments">Appendix C: Build Environments</a></li> - - <!-- Leave out - <li><a href="#mapping">Appendix D: Mapping Old Builds to the New Builds</a></li> - --> - - </ul> - </blockquote> - - <!-- ====================================================== --> - <hr> - <h2><a name="hg">Use of Mercurial</a></h2> - <blockquote> - The OpenJDK sources are maintained with the revision control system - <a href="http://mercurial.selenic.com/wiki/Mercurial">Mercurial</a>. - If you are new to Mercurial, please see the - <a href="http://mercurial.selenic.com/wiki/BeginnersGuides"> - Beginner Guides</a> - or refer to the <a href="http://hgbook.red-bean.com/"> - Mercurial Book</a>. - The first few chapters of the book provide an excellent overview of - Mercurial, what it is and how it works. - <br> - For using Mercurial with the OpenJDK refer to the - <a href="http://openjdk.java.net/guide/repositories.html#installConfig"> - Developer Guide: Installing and Configuring Mercurial</a> - section for more information. - - <h3><a name="get_source">Getting the Source</a></h3> - <blockquote> - To get the entire set of OpenJDK Mercurial repositories - use the script <code>get_source.sh</code> located in the - root repository: - <blockquote> - <code> - hg clone http://hg.openjdk.java.net/jdk8/jdk8 - <i>YourOpenJDK</i> - <br> - cd <i>YourOpenJDK</i> - <br> - bash ./get_source.sh - </code> - </blockquote> - Once you have all the repositories, keep in mind that each - repository is its own independent repository. - You can also re-run <code>./get_source.sh</code> anytime 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 - <code>hg</code> command to each of the repositories. - For example, the script <code>make/scripts/hgforest.sh</code> - can be used to repeat the same <code>hg</code> - command on every repository, e.g. - <blockquote> - <code> - cd <i>YourOpenJDK</i> - <br> - bash ./make/scripts/hgforest.sh status - </code> - </blockquote> - </blockquote> - - <h3><a name="repositories">Repositories</a></h3> - <blockquote> - <p>The set of repositories and what they contain:</p> - <table border="1"> - <thead> - <tr> - <th>Repository</th> - <th>Contains</th> - </tr> - </thead> - <tbody> - <tr> - <td> - . (root) - </td> - <td> - common configure and makefile logic - </td> - </tr> - <tr> - <td> - hotspot - </td> - <td> - source code and make files for building - the OpenJDK Hotspot Virtual Machine - </td> - </tr> - <tr> - <td> - langtools - </td> - <td> - source code for the OpenJDK javac and language tools - </td> - </tr> - <tr> - <td> - jdk - </td> - <td> - source code and make files for building - the OpenJDK runtime libraries and misc files - </td> - </tr> - <tr> - <td> - jaxp - </td> - <td> - source code for the OpenJDK JAXP functionality - </td> - </tr> - <tr> - <td> - jaxws - </td> - <td> - source code for the OpenJDK JAX-WS functionality - </td> - </tr> - <tr> - <td> - corba - </td> - <td> - source code for the OpenJDK Corba functionality - </td> - </tr> - <tr> - <td> - nashorn - </td> - <td> - source code for the OpenJDK JavaScript implementation - </td> - </tr> - </tbody> - </table> - </blockquote> - - <h3><a name="guidelines">Repository Source Guidelines</a></h3> - <blockquote> - There are some very basic guidelines: - <ul> - <li> - 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. - </li> - <li> - Files with execute permissions should not be added - to the source repositories. - </li> - <li> - 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 - <code>build/</code> directory. - </li> - <li> - 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). - </li> - <li> - The <tt>.hgignore</tt> file in each repository - must exist and should - include <tt>^build/</tt>, <tt>^dist/</tt> and - optionally any - <tt>nbproject/private</tt> directories. - <strong>It should NEVER</strong> include - anything in the - <tt>src/</tt> or <tt>test/</tt> - or any managed directory area of a repository. - </li> - <li> - Directory names and file names should never contain - blanks or - non-printing characters. - </li> - <li> - Generated source or binary files should NEVER be added to - the repository (that includes <tt>javah</tt> output). - There are some exceptions to this rule, in particular - with some of the generated configure scripts. - </li> - <li> - Files not needed for typical building - or testing of the repository - should not be added to the repository. - </li> - </ul> - </blockquote> - - </blockquote> - - <!-- ====================================================== --> - <hr> - <h2><a name="building">Building</a></h2> - <blockquote> - 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. - <br> - Building the OpenJDK is now done with running a - <a href="#configure"><code>configure</code></a> - script which will try and find and verify you have everything - you need, followed by running - <a href="#gmake"><code>make</code></a>, e.g. - <blockquote> - <b> - <code> - bash ./configure<br> - make all - </code> - </b> - </blockquote> - Where possible the <code>configure</code> script 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, - additional <code>configure</code> options may be necessary to help <code>configure</code> - find the necessary tools for the build, or you may need to - re-visit the setup of your system due to missing software - packages. - <br> - <strong>NOTE:</strong> The <code>configure</code> script - file does not have - execute permissions and will need to be explicitly run with - <code>bash</code>, - see the <a href="#guidelines">source guidelines</a>. - - <!-- ====================================================== --> - <hr> - <h3><a name="setup">System Setup</a></h3> - <blockquote> - Before even attempting to use a system to build the OpenJDK - there are some very basic system setups needed. - For all systems: - <ul> - <li> - Be sure the GNU make utility is version 3.81 or newer, - e.g. run "<code>make -version</code>" - </li> - <li> - Install a - <a name="bootjdk">Bootstrap JDK</a>. - All OpenJDK builds require access to a previously released - JDK called the <i>bootstrap JDK</i> or <i>boot JDK.</i> - The general rule is that the bootstrap JDK - must be an instance of the previous major - release of the JDK. In addition, there may be - a requirement to use a release at or beyond a - particular update level. - <br> <br> - - <b><i>Building JDK 8 requires use of a version - of JDK 7 that is at Update 7 or newer. JDK 8 - developers should not use JDK 8 as the boot - JDK, to ensure that JDK 8 dependencies are - not introduced into the parts of the system - that are built with JDK 7.</i></b> - - <br> <br> - The JDK 7 binaries can be downloaded from Oracle's - <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html" - target="_blank">JDK 7 download site</a>. - 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 its <code>bin</code> directory - to the <code>PATH</code> environment variable. - If <code>configure</code> has any issues finding this JDK, you may - need to use the <code>configure</code> option - <code>--with-boot-jdk</code>. - </li> - <li> - Ensure that GNU make, the Bootstrap JDK, - and the compilers are all - in your PATH environment variable - </li> - </ul> - And for specific systems: - <table border="1"> - <thead> - <tr> - <th>Linux</th> - <th>Solaris</th> - <th>Windows</th> - <th>Mac OS X</th> - </tr> - </thead> - <tbody> - <tr> - <td> - Install all the software development - packages needed including - <a href="#alsa">alsa</a>, - <a href="#freetype">freetype</a>, - <a href="#cups">cups</a>, and - <a href="#xrender">xrender</a>. - <br> - See - <a href="#SDBE">specific system packages</a>. - </td> - <td> - Install all the software development - packages needed including - <a href="#studio">Studio Compilers</a>, - <a href="#freetype">freetype</a>, - <a href="#cups">cups</a>, and - <a href="#xrender">xrender</a>. - <br> - See - <a href="#SDBE">specific system packages</a>. - </td> - <td> - <ul> - <li> - Install one of - <a href="#cygwin">CYGWIN</a> or - <a href="#msys">MinGW/MSYS</a> - </li> - <li> - Install - <a href="#vs2010">Visual Studio 2010</a> - </li> - </ul> - </td> - <td> - Install - <a href="https://developer.apple.com/xcode/">XCode 4.5.2</a> - and also install the "Command line tools" found under the - preferences pane "Downloads" - </td> - </tr> - </tbody> - </table> - - <h4><a name="linux">Linux</a></h4> - <blockquote> - 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. - <br> - Note that some Linux systems have a habit of pre-populating - your environment variables for you, for example <code>JAVA_HOME</code> - might get pre-defined for you to refer to the JDK installed on - your Linux system. - You will need to unset <code>JAVA_HOME</code>. - It's a good idea to run <code>env</code> and verify the - environment variables you are getting from the default system - settings make sense for building the OpenJDK. - - </blockquote> - - <h4><a name="solaris">Solaris</a></h4> - <blockquote> - <h5><a name="studio">Studio Compilers</a></h5> - <blockquote> - At a minimum, the - <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index.htm" target="_blank"> - Studio 12 Update 1 Compilers</a> - (containing version 5.10 of the C and C++ compilers) is required, - including specific patches. - <p> - The Solaris SPARC patch list is: - <ul> - <li> - 118683-05: SunOS 5.10: Patch for profiling libraries and assembler - </li> - <li> - 119963-21: SunOS 5.10: Shared library patch for C++ - </li> - <li> - 120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch - </li> - <li> - 128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler - </li> - <li> - 141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 - </li> - <li> - 141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler - </li> - <li> - 142371-01: Sun Studio 12.1 Update 1: Patch for dbx - </li> - <li> - 143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling - </li> - <li> - 143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 - </li> - <li> - 142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools - </li> - </ul> - <p> - The Solaris X86 patch list is: - <ul> - <li> - 119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler - </li> - <li> - 119964-21: SunOS 5.10_x86: Shared library patch for C++_x86 - </li> - <li> - 120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch - </li> - <li> - 141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 backend - </li> - <li> - 128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler - </li> - <li> - 142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler - </li> - <li> - 142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools - </li> - </ul> - <p> - Place the <code>bin</code> directory in <code>PATH</code>. - <p> - The Oracle Solaris Studio Express compilers at: - <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index-jsp-142582.html" target="_blank"> - Oracle Solaris Studio Express Download site</a> - are also an option, although these compilers have not - been extensively used yet. - </blockquote> - - </blockquote> <!-- Solaris --> - - <h4><a name="windows">Windows</a></h4> - <blockquote> - - <h5><a name="toolkit">Windows Unix Toolkit</a></h5> - <blockquote> - Building on Windows requires a Unix-like environment, notably a - Unix-like shell. - There are several such environments available of which - <a href="http://www.cygwin.com/">Cygwin</a> and - <a href="http://www.mingw.org/wiki/MSYS">MinGW/MSYS</a> 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 - <a href="http://en.wikipedia.org/wiki/8.3_filename"> - "8.3" version</a>. - - <h6><a name="cygwin">CYGWIN</a></h6> - <blockquote> - 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 <code><drive>:</code> - to a virtual directory <code>/cygdrive/<drive></code>. - <p> - You can always use the <code>cygpath</code> utility to map pathnames with spaces - or the backslash character into the <code>C:/</code> style of pathname - (called 'mixed'), e.g. <code>cygpath -s -m "<i>path</i>"</code>. - </p> - <p> - Note that the use of CYGWIN creates a unique problem with regards to - setting <a href="#path"><code>PATH</code></a>. Normally on Windows - the <code>PATH</code> 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 <code>PATH</code> and - instead CYGWIN uses something like <code>/cygdrive/c/path</code> - which CYGWIN understands, but only CYGWIN understands. - </p> - <p> - The OpenJDK build requires CYGWIN version 1.7.16 or newer. - Information about CYGWIN can - be obtained from the CYGWIN website at - <a href="http://www.cygwin.com" target="_blank">www.cygwin.com</a>. - </p> - <p> - 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. - <blockquote> - <table border="1"> - <thead> - <tr> - <td>Binary Name</td> - <td>Category</td> - <td>Package</td> - <td>Description</td> - </tr> - </thead> - <tbody> - <tr> - <td>ar.exe</td> - <td>Devel</td> - <td>binutils</td> - <td> - The GNU assembler, linker and binary utilities - </td> - </tr> - <tr> - <td>make.exe</td> - <td>Devel</td> - <td>make</td> - <td> - The GNU version of the 'make' utility built for CYGWIN - </td> - </tr> - <tr> - <td>m4.exe</td> - <td>Interpreters</td> - <td>m4</td> - <td> - GNU implementation of the traditional Unix macro - processor - </td> - </tr> - <tr> - <td>cpio.exe</td> - <td>Utils</td> - <td>cpio</td> - <td> - A program to manage archives of files - </td> - </tr> - <tr> - <td>gawk.exe</td> - <td>Utils</td> - <td>awk</td> - <td> - Pattern-directed scanning and processing language - </td> - </tr> - <tr> - <td>file.exe</td> - <td>Utils</td> - <td>file</td> - <td> - Determines file type using 'magic' numbers - </td> - </tr> - <tr> - <td>zip.exe</td> - <td>Archive</td> - <td>zip</td> - <td> - Package and compress (archive) files - </td> - </tr> - <tr> - <td>unzip.exe</td> - <td>Archive</td> - <td>unzip</td> - <td> - Extract compressed files in a ZIP archive - </td> - </tr> - <tr> - <td>free.exe</td> - <td>System</td> - <td>procps</td> - <td> - Display amount of free and used memory in the system - </td> - </tr> - </tbody> - </table> - </blockquote> - Note that the CYGWIN software can conflict with other non-CYGWIN - software on your Windows system. - CYGWIN provides a - <a href="http://cygwin.com/faq/faq.using.html" target="_blank">FAQ</a> for - known issues and problems, of particular interest is the - section on - <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda" target="_blank"> - BLODA (applications that interfere with CYGWIN)</a>. - </blockquote> - - <h6><a name="msys">MinGW/MSYS</a></h6> - <blockquote> - 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 <code>bash</code> - and <code>make</code>. - See <a href="http://www.mingw.org/wiki/MSYS" target="_blank">MinGW/MSYS</a> - for more information. - <p> - Like Cygwin, MinGW/MSYS can handle different types of path formats. They - are internally converted to paths with forward slashes and drive letters - <code><drive>:</code> replaced by a virtual - directory <code>/<drive></code>. 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. <code>cl /nologo /I</code>) - because MSYS may wrongly <a href="http://mingw.org/wiki/Posix_path_conversion"> - replace such parameters by drive letters</a>. - </p> - <p> - In addition to the tools which will be installed - by default, you have - to manually install the - <code>msys-zip</code> and - <code>msys-unzip</code> packages. - This can be easily done with the MinGW command line installer: - <blockquote> - <code>mingw-get.exe install msys-zip</code> - <br> - <code>mingw-get.exe install msys-unzip</code> - </blockquote> - </blockquote> - - </blockquote> - - <h5><a name="vs2010">Visual Studio 2010 Compilers</a></h5> - <blockquote> - <p> - 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 - <code>VS100COMNTOOLS</code> which - is set by the Microsoft Visual Studio installer. - </p> - <p> - 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. - </p> - <p> - Make sure that TMP and TEMP are also set - in the environment - and refer to Windows paths that exist, - like <code>C:\temp</code>, - not <code>/tmp</code>, not <code>/cygdrive/c/temp</code>, - and not <code>C:/temp</code>. - <code>C:\temp</code> 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. - </p> - </blockquote> - - - </blockquote> <!-- Windows --> - - <h4><a name="macosx">Mac OS X</a></h4> - <blockquote> - Make sure you get the right XCode version. - </blockquote> <!-- Mac OS X --> - - </blockquote> - - <!-- ====================================================== --> - <hr> - <h3><a name="configure">Configure</a></h3> - <blockquote> - The basic invocation of the <code>configure</code> script - looks like: - <blockquote> - <b><code>bash ./configure [<i>options</i>]</code></b> - </blockquote> - This will create an output directory containing the - "configuration" and setup an area for the build result. - This directory typically looks like: - <blockquote> - <b><code>build/linux-x64-normal-server-release</code></b> - </blockquote> - <code>configure</code> will 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 - <a href="#configureoptions">the <code>configure</code> options</a>. - <p> - Some examples: - </p> - <table border="1"> - <thead> - <tr> - <th>Description</th> - <th>Configure Command Line</th> - </tr> - </thead> - <tbody> - <tr> - <td>Windows 32bit build with freetype specified</td> - <td> - <code>bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32</code> - </td> - </tr> - <tr> - <td>Debug 64bit Build</td> - <td> - <code>bash ./configure --enable-debug --with-target-bits=64</code> - </td> - </tr> - </tbody> - </table> - - <!-- ====================================================== --> - <h4><a name="configureoptions">Configure Options</a></h4> - <blockquote> - Complete details on all the OpenJDK <code>configure</code> options can - be seen with: - <blockquote> - <b><code>bash ./configure --help=short</code></b> - </blockquote> - Use <code>-help</code> to see all the <code>configure</code> options - available. - - You can generate any number of different configurations, - e.g. debug, release, 32, 64, etc. - - Some of the more commonly used <code>configure</code> options are: - - <table border="1"> - <thead> - <tr> - <th width="300">OpenJDK Configure Option</th> - <th>Description</th> - </tr> - </thead> - <tbody> - <tr> - <td><b><code>--enable-debug</code></b></td> - <td> - set the debug level to fastdebug (this is a shorthand for - <code>--with-debug-level=fastdebug</code>) - </td> - </tr> - <tr> - <td><b><code>--with-alsa=</code></b><i>path</i></td> - <td> - select the location of the - <a name="alsa">Advanced Linux Sound Architecture (ALSA)</a> - <br> - 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. - </td> - </tr> - <tr> - <td><b><code>--with-boot-jdk=</code></b><i>path</i></td> - <td> - select the <a href="#bootjdk">Bootstrap JDK</a> - </td> - </tr> - <tr> - <td><b><code>--with-boot-jdk-jvmargs=</code></b>"<i>args</i>"</td> - <td> - provide the JVM options to be used to run the - <a href="#bootjdk">Bootstrap JDK</a> - </td> - </tr> - <tr> - <td><b><code>--with-cacerts=</code></b><i>path</i></td> - <td> - select the path to the cacerts file. - <br> - See <a href="http://en.wikipedia.org/wiki/Certificate_Authority" target="_blank"> - http://en.wikipedia.org/wiki/Certificate_Authority</a> - 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. - </td> - </tr> - <tr> - <td><b><code>--with-cups=</code></b><i>path</i></td> - <td> - select the CUPS install location - <br> - The - <a name="cups">Common UNIX Printing System (CUPS) Headers</a> - are required for building the - OpenJDK on Solaris and Linux. - The Solaris header files can be obtained by installing - the package <strong>SFWcups</strong> from the Solaris Software - Companion CD/DVD, these often will be installed into the - directory <code>/opt/sfw/cups</code>. - <br> - The CUPS header files can always be downloaded from - <a href="http://www.cups.org" target="_blank">www.cups.org</a>. - </td> - </tr> - <tr> - <td><b><code>--with-cups-include=</code></b><i>path</i></td> - <td> - select the CUPS include directory location - </td> - </tr> - <tr> - <td><b><code>--with-debug-level=</code></b><i>level</i></td> - <td> - select the debug information level of release, - fastdebug, or slowdebug - </td> - </tr> - <tr> - <td><b><code>--with-dev-kit=</code></b><i>path</i></td> - <td> - select location of the compiler install or - developer install location - </td> - </tr> - <tr> - <td><b><code>--with-freetype=</code></b><i>path</i></td> - <td> - select the freetype files to use. - <br> - Expecting the - <a name="freetype">freetype</a> libraries under - <code>lib/</code> and the - headers under <code>include/</code>. - <br> - 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. - <br> - You can always download latest FreeType version from the - <a href="http://www.freetype.org" target="_blank">FreeType website</a>. - <br> - Building the freetype 2 libraries from scratch is also possible, - however on Windows refer to the - <a href="http://freetype.freedesktop.org/wiki/FreeType_DLL"> - Windows FreeType DLL build instructions</a>. - <br> - 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 - <a href="http://freetype.sourceforge.net/freetype2/index.html"> - the SourceForge FreeType2 Home Page - </a> - for more information. - </td> - </tr> - <tr> - <td><b><code>--with-import-hotspot=</code></b><i>path</i></td> - <td> - select the location to find hotspot - binaries from a previous build to avoid building - hotspot - </td> - </tr> - <tr> - <td><b><code>--with-target-bits=</code></b><i>arg</i></td> - <td> - select 32 or 64 bit build - </td> - </tr> - <tr> - <td><b><code>--with-jvm-variants=</code></b><i>variants</i></td> - <td> - select the JVM variants to build from, comma - separated list that can include: - server, client, kernel, zero and zeroshark - </td> - </tr> - <tr> - <td><b><code>--with-memory-size=</code></b><i>size</i></td> - <td> - select the RAM size that GNU make will think - this system has - </td> - </tr> - <tr> - <td><a name="msvcrNN"><b><code>--with-msvcr-dll=</code></b><i>path</i></a></td> - <td> - select the <code>msvcr100.dll</code> - file to include in the - Windows builds (C/C++ runtime library for - Visual Studio). - <br> - This is usually picked up automatically - from the redist - directories of Visual Studio 2010. - </td> - </tr> - <tr> - <td><b><code>--with-num-cores=</code></b><i>cores</i></td> - <td> - select the number of cores to use (processor - count or CPU count) - </td> - </tr> - <tr> - <td><b><code>--with-x=</code></b><i>path</i></td> - <td> - select the location of the X11 and xrender files. - <br> - The - <a name="xrender">XRender Extension Headers</a> - are required for building the - OpenJDK on Solaris and Linux. - <br> - 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. - <br> - The Solaris XRender header files is - included with the other X11 header files - in the package <strong>SFWxwinc</strong> - on new enough versions of - Solaris and will be installed in - <code>/usr/X11/include/X11/extensions/Xrender.h</code> or - <code>/usr/openwin/share/include/X11/extensions/Xrender.h</code> - </td> - </tr> - </tbody> - </table> - </blockquote> - - </blockquote> - - <!-- ====================================================== --> - <hr> - <h3><a name="make">Make</a></h3> - <blockquote> - The basic invocation of the <code>make</code> utility - looks like: - <blockquote> - <b><code>make all</code></b> - </blockquote> - This will start the build to the output directory containing the - "configuration" that was created by the <code>configure</code> - script. Run <code>make help</code> for more information on - the available targets. - <br> - There are some of the make targets that - are of general interest: - <table border="1"> - <thead> - <tr> - <th>Make Target</th> - <th>Description</th> - </tr> - </thead> - <tbody> - <tr> - <td><i>empty</i></td> - <td>build everything but no images</td> - </tr> - <tr> - <td><b><code>all</code></b></td> - <td>build everything including images</td> - </tr> - <tr> - <td><b><code>all-conf</code></b></td> - <td>build all configurations</td> - </tr> - <tr> - <td><b><code>images</code></b></td> - <td>create complete j2sdk and j2re images</td> - </tr> - <tr> - <td><b><code>install</code></b></td> - <td>install the generated images locally, - typically in <code>/usr/local</code></td> - </tr> - <tr> - <td><b><code>clean</code></b></td> - <td>remove all files generated by make, - but not those generated by <code>configure</code></td> - </tr> - <tr> - <td><b><code>dist-clean</code></b></td> - <td>remove all files generated by both - and <code>configure</code> (basically killing the configuration)</td> - </tr> - <tr> - <td><b><code>help</code></b></td> - <td>give some help on using <code>make</code>, - including some interesting make targets</td> - </tr> - </tbody> - </table> - </blockquote> - </blockquote> - - <!-- ====================================================== --> - <hr> - <h2><a name="testing">Testing</a></h2> - <blockquote> - When the build is completed, you should see the generated - binaries and associated files in the <code>j2sdk-image</code> - directory in the output directory. - In particular, the - <code>build/<i>*</i>/images/j2sdk-image/bin</code> - directory should contain executables for the - OpenJDK tools and utilities for that configuration. - The testing tool <code>jtreg</code> will be needed - and can be found at: - <a href="http://openjdk.java.net/jtreg/" target="_blank"> - the jtreg site</a>. - The provided regression tests in the repositories - can be run with the command: - <blockquote> - <code><b>cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all</b></code> - </blockquote> - </blockquote> - - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - <!-- ====================================================== --> - - <!-- ====================================================== --> - <hr> - <h2><a name="hints">Appendix A: Hints and Tips</a></h2> - <blockquote> - - <h3><a name="faq">FAQ</a></h3> - <blockquote> - - <p> - <b>Q:</b> The <code>generated-configure.sh</code> file looks horrible! - How are you going to edit it? - <br> - <b>A:</b> The <code>generated-configure.sh</code> file is generated (think - "compiled") by the autoconf tools. The source code is - in <code>configure.ac</code> and various .m4 files in common/autoconf, - which are much more readable. - </p> - - <p> - <b>Q:</b> - Why is the <code>generated-configure.sh</code> file checked in, - if it is generated? - <br> - <b>A:</b> - If it was not generated, every user would need to have the autoconf - tools installed, and re-generate the <code>configure</code> file - 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. - </p> - - <p> - <b>Q:</b> - Do you require a specific version of autoconf for regenerating - <code>generated-configure.sh</code>? - <br> - <b>A:</b> - Yes, version 2.69 is required and should be easy - enough to aquire on all supported operating - systems. The reason for this is to avoid - large spurious changes in <code>generated-configure.sh</code>. - </p> - - <p> - <b>Q:</b> - How do you regenerate <code>generated-configure.sh</code> - after making changes to the input files? - <br> - <b>A:</b> - Regnerating <code>generated-configure.sh</code> - should always be done using the - script <code>common/autoconf/autogen.sh</code> to - ensure that the correct files get updated. This - script should also be run after mercurial tries to - merge <code>generated-configure.sh</code> as a - merge of the generated file is not guaranteed to - be correct. - </p> - - <p> - <b>Q:</b> - What are the files in <code>common/makefiles/support/*</code> for? - They look like gibberish. - <br> - <b>A:</b> - 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! :-) - </p> - - <p> - <b>Q:</b> - I want to see the output of the commands that make runs, - like in the old build. How do I do that? - <br> - <b>A:</b> - You specify the <code>LOG</code> variable to make. There are - several log levels: - </p> - <blockquote> - <ul> - <li> - <b><code>warn</code></b> — Default and very quiet. - </li> - <li> - <b><code>info</code></b> — Shows more progress information - than warn. - </li> - <li> - <b><code>debug</code></b> — Echos all command lines and - prints all macro calls for compilation definitions. - </li> - <li> - <b><code>trace</code></b> — Echos all $(shell) command - lines as well. - </li> - </ul> - </blockquote> - - <p> - <b>Q:</b> - When do I have to re-run <code>configure</code>? - <br> - <b>A:</b> - Normally you will run <code>configure</code> only 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 the <code>configure</code> script. - </p> - - <p> - <b>Q:</b> - I have added a new source file. Do I need to modify the makefiles? - <br> - <b>A:</b> - 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 sources for other - libraries. In these cases it was simply easier to create include lists - rather than excludes. - </p> - - <p> - <b>Q:</b> - When I run <code>configure --help</code>, I see many strange options, - like <code>--dvidir</code>. What is this? - <br> - <b>A:</b> - 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, - use <code>configure --help=short</code> instead. - </p> - - <p> - <b>Q:</b> - <code>configure</code> provides OpenJDK-specific features such as - <code>--with-builddeps-server</code> that are not - described in this document. What about those? - <br> - <b>A:</b> - 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. Others depend on - pieces of code or infrastructure that is currently - not ready for prime time. - </p> - - <p> - <b>Q:</b> - How will you make sure you don't break anything? - <br> - <b>A:</b> - 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. - </p> - - <p> - <b>Q:</b> - I noticed this thing X in the build that looks very broken by design. - Why don't you fix it? - <br> - <b>A:</b> - 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. - </p> - - <p> - <b>Q:</b> - The code in the new build system is not that well-structured. - Will you fix this? - <br> - <b>A:</b> - 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. - </p> - - <p> - <b>Q:</b> - Is anything able to use the results of the new build's default make target? - <br> - <b>A:</b> - 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 the <code>images</code> - 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...) - </p> - - <p> - <b>Q:</b> - I usually set a specific environment variable when building, - but I can't find the equivalent in the new build. - What should I do? - <br> - <b>A:</b> - It might very well be that we have neglected to add support for - an option that was actually used from outside the build system. - Email us and we will add support for it! - </p> - - </blockquote> - - <h3><a name="performance">Build Performance Tips</a></h3> - <blockquote> - - <p>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 <code>configure</code> script 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:</p> - - <ul> - <li> - <b><code>--with-num-cores</code></b> - — - number of cores in the build system, - e.g. <code>--with-num-cores=8</code> - </li> - <li> - <b><code>--with-memory-size</code></b> - — memory (in MB) available in the build system, - e.g. <code>--with-memory-size=1024</code> - </li> - </ul> - - <p>It might also be necessary to specify the JVM arguments passed - to the Bootstrap JDK, using e.g. - <code>--with-boot-jdk-jvmargs="-Xmx8G -enableassertions"</code>. - Doing this will override the default JVM arguments - passed to the Bootstrap JDK.</p> - - - <p>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.</p> - - <p>At the end of a successful execution of <code>configure</code>, - 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!</p> - - <h4>Building with ccache</h4> - - <p>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.</p> - - <h4>Building on local disk</h4> - - <p>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.</p> - - <h4>Building only one JVM</h4> - - <p>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 <code>--with-jvm-variants=client,server</code>.</p> - - <h4>Selecting the number of cores to build on</h4> - - <p>By default, <code>configure</code> will 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 a <code>configure</code> - basis) using <code>--with-num-cores=N</code> or for a single build - only (on a make basis), using <code>make JOBS=N</code>.</p> - - <p>If you want to make a slower build just this time, to save some CPU - power for other processes, you can run - e.g. <code>make JOBS=2</code>. This will force the makefiles - to only run 2 parallel processes, or even <code>make JOBS=1</code> - which will disable parallelism.</p> - - <p>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 <code>configure</code> with - <code>--with-num-cores=2</code>, making 2 the default. - If you want to run with more - cores, run <code>make JOBS=8</code></p> - - </blockquote> - - <h3><a name="troubleshooting">Troubleshooting</a></h3> - <blockquote> - - <h4>Solving build problems</h4> - - <blockquote> - 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 adding <code>LOG=debug</code> to your make command line. - <br> - The build log (with both stdout and stderr intermingled, - basically the same as you see on your console) can be found as - <code>build.log</code> in your build directory. - <br> - You can ask for help on build problems with the new build system - on either the - <a href="http://mail.openjdk.java.net/mailman/listinfo/build-dev"> - build-dev</a> - or the - <a href="http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev"> - build-infra-dev</a> - mailing lists. Please include the relevant parts - of the build log. - <br> - 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 the <code>configure</code> log 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 - <code>configure</code> had in finding things. - <br> - Some of the more common problems with builds are briefly - described - below, with suggestions for remedies. - <ul> - <li> - <b>Corrupted Bundles on Windows:</b> - <blockquote> - 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. - </blockquote> - </li> - <li> - <b>Slow Builds:</b> - <blockquote> - If your build machine seems to be overloaded from too many - simultaneous C++ compiles, try setting the - <code>JOBS=1</code> on the <code>make</code> command line. - Then try increasing the count slowly to an acceptable - level for your system. Also: - <blockquote> - Creating the javadocs can be very slow, - if you are running - javadoc, consider skipping that step. - <br> - 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. - <br> - Faster compiles are possible using a tool called - <a href="http://ccache.samba.org/" target="_blank">ccache</a>. - </blockquote> - </blockquote> - </li> - <li> - <b>File time issues:</b> - <blockquote> - If you see warnings that refer to file time stamps, e.g. - <blockquote> - <i>Warning message:</i><code> - File `xxx' has modification time in - the future.</code> - <br> - <i>Warning message:</i> <code> Clock skew detected. - Your build may - be incomplete.</code> - </blockquote> - 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. - <p> - If you see these warnings, reset the clock on the - build - machine, run "<code><i>gmake</i> clobber</code>" - or delete the directory - containing the build output, and restart the - build from the beginning. - </blockquote> - </li> - <li> - <b>Error message: - <code>Trouble writing out table to disk</code></b> - <blockquote> - 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: - <blockquote> - <code>make JOBS=1</code> - </blockquote> - to reduce the load on the system. - </blockquote> - </li> - <li> - <b>Error Message: - <code>libstdc++ not found:</code></b> - <blockquote> - 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. - </blockquote> - </li> - <li> - <b>Linux Error Message: - <code>cannot restore segment prot after reloc</code></b> - <blockquote> - This is probably an issue with SELinux (See - <a href="http://en.wikipedia.org/wiki/SELinux" target="_blank"> - http://en.wikipedia.org/wiki/SELinux</a>). - Parts of the VM is built without the <code>-fPIC</code> for - performance reasons. - <p> - To completely disable SELinux: - <ol> - <li><code>$ su root</code></li> - <li><code># system-config-securitylevel</code></li> - <li><code>In the window that appears, select the SELinux tab</code></li> - <li><code>Disable SELinux</code></li> - </ol> - <p> - Alternatively, instead of completely disabling it you could - disable just this one check. - <ol> - <li>Select System->Administration->SELinux Management</li> - <li>In the SELinux Management Tool which appears, - select "Boolean" from the menu on the left</li> - <li>Expand the "Memory Protection" group</li> - <li>Check the first item, labeled - "Allow all unconfined executables to use - libraries requiring text relocation ..."</li> - </ol> - </blockquote> - </li> - <li> - <b>Windows Error Messages:</b> - <br> - <code>*** fatal error - couldn't allocate heap, ... </code> - <br> - <code>rm fails with "Directory not empty"</code> - <br> - <code>unzip fails with "cannot create ... Permission denied"</code> - <br> - <code>unzip fails with "cannot create ... Error 50"</code> - <br> - <blockquote> - The CYGWIN software can conflict with other non-CYGWIN - software. See the CYGWIN FAQ section on - <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda" target="_blank"> - BLODA (applications that interfere with CYGWIN)</a>. - </blockquote> - </li> - <li> - <b>Windows Error Message: <code>spawn failed</code></b> - <blockquote> - 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. - </blockquote> - </li> - </ul> - </blockquote> - - </blockquote> <!-- Troubleshooting --> - - </blockquote> <!-- Appendix A --> - - <!-- ====================================================== --> - <hr> - <h2><a name="gmake">Appendix B: GNU make</a></h2> - <blockquote> - - The Makefiles in the OpenJDK are only valid when used with the - GNU version of the utility command <code>make</code> - (usually called <code>gmake</code> on Solaris). - A few notes about using GNU make: - <ul> - <li> - You need GNU make version 3.81 or newer. - If the GNU make utility on your systems is not - 3.81 or newer, - see <a href="#buildgmake">"Building GNU make"</a>. - </li> - <li> - Place the location of the GNU make binary in the - <code>PATH</code>. - </li> - <li> - <strong>Solaris:</strong> - Do NOT use <code>/usr/bin/make</code> on Solaris. - If your Solaris system has the software - from the Solaris Developer Companion CD installed, - you should try and use <code>gmake</code> - which will be located in either the - <code>/usr/bin</code>, <code>/opt/sfw/bin</code> or - <code>/usr/sfw/bin</code> directory. - </li> - <li> - <strong>Windows:</strong> - Make sure you start your build inside a bash shell. - </li> - <li> - <strong>Mac OS X:</strong> - The XCode "command line tools" must be installed on your Mac. - </li> - </ul> - <p> - Information on GNU make, and access to ftp download sites, are - available on the - <a href="http://www.gnu.org/software/make/make.html" target="_blank"> - GNU make web site - </a>. - The latest source to GNU make is available at - <a href="http://ftp.gnu.org/pub/gnu/make/" target="_blank"> - ftp.gnu.org/pub/gnu/make/</a>. - </p> - - <h3><a name="buildgmake">Building GNU make</a></h3> - <blockquote> - First step is to get the GNU make 3.81 or newer source from - <a href="http://ftp.gnu.org/pub/gnu/make/" target="_blank"> - ftp.gnu.org/pub/gnu/make/</a>. - Building is a little different depending on the OS but is - basically done with: - <blockquote> - <code>bash ./configure</code> - <br> - <code>make</code> - </blockquote> - </blockquote> - - </blockquote> <!-- Appendix B --> - - <!-- ====================================================== --> - <hr> - <h2><a name="buildenvironments">Appendix C: Build Environments</a></h2> - <blockquote> - - <h3><a name="MBE">Minimum Build Environments</a></h3> - <blockquote> - 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. - <p> - 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. - <p> - 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. - <p> - 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.<br> - <b>NOTE: We expect a change here off these older Windows OS releases - and to a 'less older' one, probably Windows 2008R2 X64.</b> - <p> - With Linux, it was just a matter of picking a - stable distribution that is a good representative for Linux - in general.<br> - <b>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.</b> - <p> - 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. - <p> - Compilation problems with newer or different C/C++ compilers is a - common problem. - Similarly, compilation problems related to changes to the - <code>/usr/include</code> or 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. - </p> - <table border="1"> - <thead> - <tr> - <th>Base OS and Architecture</th> - <th>OS</th> - <th>C/C++ Compiler</th> - <th>Bootstrap JDK</th> - <th>Processors</th> - <th>RAM Minimum</th> - <th>DISK Needs</th> - </tr> - </thead> - <tbody> - <tr> - <td>Linux X86 (32-bit) and X64 (64-bit)</td> - <td>Fedora 9</td> - <td>gcc 4.3 </td> - <td>JDK 7u7</td> - <td>2 or more</td> - <td>1 GB</td> - <td>6 GB</td> - </tr> - <tr> - <td>Solaris SPARC (32-bit) and SPARCV9 (64-bit)</td> - <td>Solaris 10 Update 6</td> - <td>Studio 12 Update 1 + patches</td> - <td>JDK 7u7</td> - <td>4 or more</td> - <td>4 GB</td> - <td>8 GB</td> - </tr> - <tr> - <td>Solaris X86 (32-bit) and X64 (64-bit)</td> - <td>Solaris 10 Update 6</td> - <td>Studio 12 Update 1 + patches</td> - <td>JDK 7u7</td> - <td>4 or more</td> - <td>4 GB</td> - <td>8 GB</td> - </tr> - <tr> - <td>Windows X86 (32-bit)</td> - <td>Windows XP</td> - <td>Microsoft Visual Studio C++ 2010 Professional Edition</td> - <td>JDK 7u7</td> - <td>2 or more</td> - <td>2 GB</td> - <td>6 GB</td> - </tr> - <tr> - <td>Windows X64 (64-bit)</td> - <td>Windows Server 2003 - Enterprise x64 Edition</td> - <td>Microsoft Visual Studio C++ 2010 Professional Edition</td> - <td>JDK 7u7</td> - <td>2 or more</td> - <td>2 GB</td> - <td>6 GB</td> - </tr> - <tr> - <td>Mac OS X X64 (64-bit)</td> - <td>Mac OS X 10.7 "Lion"</td> - <td>XCode 4.5.2 or newer</td> - <td>JDK 7u7</td> - <td>2 or more</td> - <td>4 GB</td> - <td>6 GB</td> - </tr> - </tbody> - </table> - </blockquote> - - <!-- ====================================================== --> - <hr> - <h3><a name="SDBE">Specific Developer Build Environments</a></h3> - <blockquote> - We won't be listing all the possible environments, but - we will try to provide what information we have available to us. - <p> - <strong>NOTE: The community can help out by updating - this part of the document. - </strong> - - <h4><a name="fedora">Fedora</a></h4> - <blockquote> - After installing the latest - <a href="http://fedoraproject.org">Fedora</a> - you need to install several build dependencies. - The simplest way to do it is to execute the - following commands as user <code>root</code>: - <blockquote> - <code>yum-builddep java-1.7.0-openjdk</code> - <br> - <code>yum install gcc gcc-c++</code> - </blockquote> - <p> - In addition, it's necessary to set a few environment - variables for the build: - <blockquote> - <code>export LANG=C</code> - <br> - <code>export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}"</code> - </blockquote> - </blockquote> - - - <h4><a name="centos">CentOS 5.5</a></h4> - <blockquote> - After installing - <a href="http://www.centos.org/">CentOS 5.5</a> - you need to make sure you have - the following Development bundles installed: - <blockquote> - <ul> - <li>Development Libraries</li> - <li>Development Tools</li> - <li>Java Development</li> - <li>X Software Development (Including XFree86-devel)</li> - </ul> - </blockquote> - <p> - Plus the following packages: - <blockquote> - <ul> - <li>cups devel: Cups Development Package</li> - <li>alsa devel: Alsa Development Package</li> - <li>Xi devel: libXi.so Development Package</li> - </ul> - </blockquote> - <p> - 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 - <a href="http://downloads.sourceforge.net/freetype"> - the freetype site</a>. - Build and install with something like: - <blockquote> - <code>bash ./configure</code> - <br> - <code>make</code> - <br> - <code>sudo -u root make install</code> - </blockquote> - <p> - Mercurial packages could not be found easily, but a Google - search should find ones, and they usually include Python if - it's needed. - </blockquote> - - <h4><a name="debian">Debian 5.0 (Lenny)</a></h4> - <blockquote> - After installing <a href="http://debian.org">Debian</a> 5 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands as user <code>root</code>: - <blockquote> - <code>aptitude build-dep openjdk-7</code> - <br> - <code>aptitude install openjdk-7-jdk libmotif-dev</code> - </blockquote> - <p> - In addition, it's necessary to set a few environment - variables for the build: - <blockquote> - <code>export LANG=C</code> - <br> - <code>export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"</code> - </blockquote> - </blockquote> - - <h4><a name="ubuntu">Ubuntu 12.04</a></h4> - <blockquote> - After installing <a href="http://ubuntu.org">Ubuntu</a> 12.04 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands: - <blockquote> - <code>sudo aptitude build-dep openjdk-7</code> - <br> - <code>sudo aptitude install openjdk-7-jdk</code> - </blockquote> - <p> - In addition, it's necessary to set a few environment - variables for the build: - <blockquote> - <code>export LANG=C</code> - <br> - <code>export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"</code> - </blockquote> - </blockquote> - - <h4><a name="opensuse">OpenSUSE 11.1</a></h4> - <blockquote> - After installing <a href="http://opensuse.org">OpenSUSE</a> 11.1 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands: - <blockquote> - <code>sudo zypper source-install -d java-1_7_0-openjdk</code> - <br> - <code>sudo zypper install make</code> - </blockquote> - <p> - In addition, it is necessary to set a few environment - variables for the build: - <blockquote> - <code>export LANG=C</code> - <br> - <code>export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}"</code> - </blockquote> - <p> - Finally, you need to unset the <code>JAVA_HOME</code> - environment variable: - <blockquote> - <code>export -n JAVA_HOME</code> - </blockquote> - </blockquote> - - <h4><a name="mandriva">Mandriva Linux One 2009 Spring</a></h4> - <blockquote> - After installing <a href="http://mandriva.org">Mandriva</a> - 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 <code>root</code>: - <blockquote> - <code>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</code> - </blockquote> - <p> - In addition, it is necessary to set a few environment - variables for the build: - <blockquote> - <code>export LANG=C</code> - <br> - <code>export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}"</code> - </blockquote> - </blockquote> - - <h4><a name="opensolaris">OpenSolaris 2009.06</a></h4> - <blockquote> - After installing <a href="http://opensolaris.org">OpenSolaris</a> 2009.06 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands: - <blockquote> - <code>pfexec pkg install SUNWgmake SUNWj7dev - sunstudioexpress SUNWcups SUNWzip SUNWunzip SUNWxwhl - SUNWxorg-headers SUNWaudh SUNWfreetype2</code> - </blockquote> - <p> - In addition, it is necessary to set a few environment - variables for the build: - <blockquote> - <code>export LANG=C</code> - <br> - <code>export PATH="/opt/SunStudioExpress/bin:${PATH}"</code> - </blockquote> - </blockquote> - - </blockquote> - - </blockquote> <!-- Appendix C --> - - <!-- ====================================================== --> - - <!-- Leave out Appendix D -- - -<hr> -<h2><a name="mapping">Appendix D: Mapping Old to New</a></h2> -<blockquote> - <p>This table will help you convert some idioms of the old build - system to the new build system.</p> - <table summary="Cheat sheet for converting from old to new build system"> - <tr valign="top"> - <th>In the old build system, you used to...</th> - <th>In the new build system, you should ...</th> - </tr> - <tr valign="top"> - <td>run <code>make sanity</code></td> - <td>run <code>bash ./configure</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_OUTPUTDIR=build/my-special-output</code></td> - <td>before building the first time: - <br> - <code>cd build/my-special-output</code> - <br> - <code>bash ../../configure</code> - <br> - to build: - <br> - <code>cd build/my-special-output</code> - <br> - <code>make</code> - </td> - </tr> - <tr valign="top"> - <td>set <code>ALT_BOOTDIR=/opt/java/jdk7</code></td> - <td>run <code>configure --with-boot-jdk=/opt/java/jdk7</code></td> - </tr> - <tr valign="top"> - <td>run <code>make ARCH_DATA_MODEL=32</code></td> - <td>run <code>configure --with-target-bits=32</code></td> - </tr> - <tr valign="top"> - <td>set <code>BUILD_CLIENT_ONLY=true</code></td> - <td>run <code>configure --with-jvm-variants=client</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_FREETYPE_LIB_PATH=/opt/freetype/lib</code> - and <code>ALT_FREETYPE_HEADERS_PATH=/opt/freetype/include</code></td> - <td>run <code>configure --with-freetype=/opt/freetype</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_CUPS_HEADERS_PATH=/opt/cups/include</code></td> - <td>run <code>configure --with-cups=/opt/cups</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_OPENWIN_HOME=/opt/X11R6</code></td> - <td>run <code>configure --with-x=/opt/X11R6</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_MSVCRNN_DLL_PATH=c:/vc_redist</code></td> - <td>run <code>configure --with-msvcr100dll=/cygdrive/c/vc_redist</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_COMPILER_PATH=/opt/my-gcc/bin/gcc</code></td> - <td>run <code>CC=/opt/my-gcc/bin/gcc configure</code> - or <code>CXX=/opt/my-gcc/bin/g++ configure</code> - </td> - </tr> - <tr valign="top"> - <td>set <code>BUILD_HEADLESS_ONLY=true</code></td> - <td>run <code>configure --disable-headful</code></td> - </tr> - <tr valign="top"> - <td>set <code>ALT_DEVTOOLS_PATH=/opt/mytools</code></td> - <td>just run <code>configure</code>, - your tools should be detected automatically. - If you have an unusual configuration, - add the tools directory to your <code>PATH</code>. - </td> - </tr> - <tr valign="top"> - <td>set <code>ALT_DROPS_DIR=/home/user/dropdir</code></td> - <td>source drops are not used anymore</td> - </tr> - <tr valign="top"> - <td>set <code>USE_ONLY_BOOTDIR_TOOLS=true</code></td> - <td>not needed, <code>configure</code> should always do the Right Thing automatically</td> - </tr> - <tr valign="top"> - <td>set <code>ALT_JDK_IMPORT_PATH=/opt/java/import-jdk</code> - or <code>ALT_BUILD_JDK_IMPORT_PATH=/opt/java/import-jdk</code> - </td> - <td>Importing JDKs is no longer possible, - but hotspot can be imported using - <code>--with-import-hotspot</code>. - Documentation on how to achieve a - similar solution will come soon! - </td> - </tr> - <tr valign="top"> - <td>set <code>EXTRA_CFLAGS=-Xfoo</code></td> - <td>run <code>CFLAGS=-Xfoo configure</code></td> - </tr> - <tr valign="top"> - <td>set <code>CROSS_COMPILE_ARCH=i586</code></td> - <td>see <a href="#sec7.3"> section 7.3, Cross-compilation</a></td> - </tr> - <tr valign="top"> - <td>set <code>SKIP_BOOT_CYCLE=false</code></td> - <td>Run <code>make bootcycle-images</code>.</td> - </tr> - </table> - - <h3><a name="variables">Environment/Make Variables</a></h3> - <p> - Some of the - environment or make variables (just called <b>variables</b> in this - document) that can impact the build are: - <blockquote> - <dl> - <dt><a name="path"><code>PATH</code></a> </dt> - <dd>Typically you want to set the <code>PATH</code> to include: - <ul> - <li>The location of the GNU make binary</li> - <li>The location of the Bootstrap JDK <code>java</code> - (see <a href="#bootjdk">Bootstrap JDK</a>)</li> - <li>The location of the C/C++ compilers - (see <a href="#compilers"><code>compilers</code></a>)</li> - <li>The location or locations for the Unix command utilities - (e.g. <code>/usr/bin</code>)</li> - </ul> - </dd> - <dt><code>MILESTONE</code> </dt> - <dd> - The milestone name for the build (<i>e.g.</i>"beta"). - The default value is "internal". - </dd> - <dt><code>BUILD_NUMBER</code> </dt> - <dd> - The build number for the build (<i>e.g.</i> "b27"). - The default value is "b00". - </dd> - <dt><a name="arch_data_model"><code>ARCH_DATA_MODEL</code></a></dt> - <dd>The <code>ARCH_DATA_MODEL</code> 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 <code>ARCH_DATA_MODEL</code> to <code>32</code> for generating 32-bit binaries, - or to <code>64</code> for generating 64-bit binaries. - </dd> - <dt><a name="ALT_BOOTDIR"><code>ALT_BOOTDIR</code></a></dt> - <dd> - The location of the bootstrap JDK installation. - See <a href="#bootjdk">Bootstrap JDK</a> for more information. - You should always install your own local Bootstrap JDK and - always set <code>ALT_BOOTDIR</code> explicitly. - </dd> - <dt><a name="ALT_OUTPUTDIR"><code>ALT_OUTPUTDIR</code></a> </dt> - <dd> - An override for specifying the (absolute) path of where the - build output is to go. - The default output directory will be build/<i>platform</i>. - </dd> - <dt><a name="ALT_COMPILER_PATH"><code>ALT_COMPILER_PATH</code></a> </dt> - <dd> - The location of the C/C++ compiler. - The default varies depending on the platform. - </dd> - <dt><code><a name="ALT_CACERTS_FILE">ALT_CACERTS_FILE</a></code></dt> - <dd> - The location of the <a href="#cacerts">cacerts</a> file. - The default will refer to - <code>jdk/src/share/lib/security/cacerts</code>. - </dd> - <dt><a name="ALT_CUPS_HEADERS_PATH"><code>ALT_CUPS_HEADERS_PATH</code></a> </dt> - <dd> - The location of the CUPS header files. - See <a href="#cups">CUPS information</a> for more information. - If this path does not exist the fallback path is - <code>/usr/include</code>. - </dd> - <dt><a name="ALT_FREETYPE_LIB_PATH"><code>ALT_FREETYPE_LIB_PATH</code></a></dt> - <dd> - The location of the FreeType shared library. - See <a href="#freetype">FreeType information</a> for details. - </dd> - <dt><a name="ALT_FREETYPE_HEADERS_PATH"><code>ALT_FREETYPE_HEADERS_PATH</code></a></dt> - <dd> - The location of the FreeType header files. - See <a href="#freetype">FreeType information</a> for details. - </dd> - <dt><a name="ALT_JDK_DEVTOOLS_PATH"><code>ALT_JDK_DEVTOOLS_PATH</code></a></dt> - <dd> - The default root location of the devtools. - The default value is - <code>$(ALT_SLASH_JAVA)/devtools</code>. - </dd> - <dt><code><a name="ALT_DEVTOOLS_PATH">ALT_DEVTOOLS_PATH</a></code> </dt> - <dd> - The location of tools like the - <a href="#zip"><code>zip</code> and <code>unzip</code></a> - binaries, but might also contain the GNU make utility - (<code><i>gmake</i></code>). - 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 - <code>$(ALT_JDK_DEVTOOLS_PATH)/linux/bin</code>, - on Solaris - <code>$(ALT_JDK_DEVTOOLS_PATH)/<i>{sparc,i386}</i>/bin</code>, - and on Windows with CYGWIN - <code>/usr/bin</code>. - </dd> - <dt><a name="ALT_UNIXCCS_PATH"><code>ALT_UNIXCCS_PATH</code></a></dt> - <dd> - <strong>Solaris only:</strong> - An override for specifying where the Unix CCS - command set are located. - The default location is <code>/usr/ccs/bin</code> - </dd> - <dt><a name="ALT_SLASH_JAVA"><code>ALT_SLASH_JAVA</code></a></dt> - <dd> - The default root location for many of the ALT path locations - of the following ALT variables. - The default value is - <code>"/java"</code> on Solaris and Linux, - <code>"J:"</code> on Windows. - </dd> - - <dt><a name="ALT_OPENWIN_HOME"><code>ALT_OPENWIN_HOME</code></a></dt> - <dd> - 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 <code>/usr/X11R6/</code>. - </dd> - <dt><strong>Windows specific:</strong></dt> - <dd> - <dl> - <dt><a name="ALT_WINDOWSSDKDIR"><code>ALT_WINDOWSSDKDIR</code></a> </dt> - <dd> - 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 - <br> - <code>c:\Program Files\Microsoft SDKs\Windows\v7.0a</code> - </dd> - <dt><code><a name="ALT_DXSDK_PATH">ALT_DXSDK_PATH</a></code> </dt> - <dd> - The location of the - <a href="#dxsdk">Microsoft DirectX 9 SDK</a>. - The default will be to try and use the DirectX environment - variable <code>DXSDK_DIR</code>, - failing that, look in <code>C:/DXSDK</code>. - </dd> - <dt><code><a name="ALT_MSVCRNN_DLL_PATH">ALT_MSVCRNN_DLL_PATH</a></code> </dt> - <dd> - The location of the - <a href="#msvcrNN"><code>MSVCR100.DLL</code></a>. - </dd> - </dl> - </dd> - <dt><strong>Cross-Compilation Support:</strong></dt> - <dd> - <dl> - <dt><a name="CROSS_COMPILE_ARCH"><code>CROSS_COMPILE_ARCH</code></a> </dt> - <dd> - 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 - <a href="#ALT_COMPILER_PATH"><code>ALT_COMPILER_PATH</code></a> - is set - to point to the cross-compiler and that any - cross-compilation specific flags - are passed using - <a href="#EXTRA_CFLAGS"><code>EXTRA_CFLAGS</code></a>. - The <a href="#ALT_OPENWIN_HOME"><code>ALT_OPENWIN_HOME</code></a> - 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. - </dd> - <dt><code><a name="EXTRA_CFLAGS">EXTRA_CFLAGS</a></code> </dt> - <dd> - Used to pass cross-compilation options to the - cross-compiler. - These are added to the <code>CFLAGS</code> - and <code>CXXFLAGS</code> variables. - </dd> - <dt><code><a name="USE_ONLY_BOOTDIR_TOOLS">USE_ONLY_BOOTDIR_TOOLS</a></code> </dt> - <dd> - 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 - (<code>javac</code>, <code>javah</code>, <code>jar</code>) - just built (which can't execute on the build host). - </dd> - <dt><code><a name="HOST_CC">HOST_CC</a></code> </dt> - <dd> - 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 <code>/usr/bin/gcc</code>; - on other platforms it must be - set explicitly. - </dd> - </dl> - <dt><strong>Specialized Build Options:</strong></dt> - <dd> - Some build variables exist to support specialized build - environments and/or specialized - build products. Their use is only supported in those contexts: - <dl> - <dt><code><a name="BUILD_CLIENT_ONLY">BUILD_CLIENT_ONLY</a></code> </dt> - <dd> - 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 <code>jvm.cfg</code> 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. - </dd> - <dt><code><a name="BUILD_HEADLESS_ONLY"></a>BUILD_HEADLESS_ONLY</code> </dt> - <dd> - Used when the build environment has no graphical - capabilities at all. This - excludes building anything that requires graphical - libraries to be available. - </dd> - <dt><code><a name="JAVASE_EMBEDDED"></a>JAVASE_EMBEDDED</code> </dt> - <dd> - 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. - </dd> - <dt><code><a name="LIBZIP_CAN_USE_MMAP">LIBZIP_CAN_USE_MMAP</a></code> </dt> - <dd> - If set to false, disables the use of mmap by the - zip utility. Otherwise, - mmap will be used. - </dd> - <dt><code><a name="COMPRESS_JARS"></a>COMPRESS_JARS</code> </dt> - <dd> - If set to true, causes certain jar files that - would otherwise be built without - compression, to use compression. - </dd> - </dl> - </dd> - </dl> - </blockquote> - -</blockquote> <!-- Appendix D --> - - <!-- ====================================================== --> - <hr> - <p>End of OpenJDK README-builds.html document.<br>Please come again! - <hr> - - </body> -</html> |