--- a/.hgignore Thu Oct 22 08:47:39 2015 -0700
+++ b/.hgignore Thu Oct 22 11:12:30 2015 -0700
@@ -5,3 +5,5 @@
^.hgtip
^.bridge2
.DS_Store
+.metadata/
+.recommenders/
--- a/README-builds.html Thu Oct 22 08:47:39 2015 -0700
+++ b/README-builds.html Thu Oct 22 11:12:30 2015 -0700
@@ -1,2492 +1,1386 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
- <head>
- <title>OpenJDK Build README</title>
- </head>
- <body style="background-color:aquamarine">
+ <head>
+ <title>OpenJDK Build README</title>
+ </head>
+ <body>
+<p><img src="http://openjdk.java.net/images/openjdk.png" alt="OpenJDK" title="" /></p>
+
+<h1>OpenJDK Build README</h1>
+
+<hr />
+
+<p><a name="introduction"></a></p>
+
+<h2>Introduction</h2>
+
+<p>This README file contains build instructions for the
+<a href="http://openjdk.java.net">OpenJDK</a>. Building the source code for the OpenJDK
+requires a certain degree of technical expertise.</p>
- <!-- ====================================================== -->
- <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>
+<h3>!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!</h3>
+
+<p>Some Headlines:</p>
- <!-- ====================================================== -->
- <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.
+<ul>
+<li>The build is now a "<code>configure && make</code>" style build</li>
+<li>Any GNU make 3.81 or newer should work, except on Windows where 4.0 or newer
+is recommended.</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>
+
+<hr />
- <!-- ====================================================== -->
- <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, except on
- Windows where 4.0 or newer is recommended.
- </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>
+<h2>Contents</h2>
- <!-- ====================================================== -->
- <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>
+<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>
- <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>
+<hr />
- <!-- Leave out
- <li><a href="#mapping">Appendix D: Mapping Old Builds to the New Builds</a></li>
- -->
+<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>
+</ul>
- </ul>
- </blockquote>
+<hr />
+
+<p><a name="hg"></a></p>
+
+<h2>Use of Mercurial</h2>
- <!-- ====================================================== -->
- <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.
+<p>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.</p>
+
+<p>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.</p>
+
+<p><a name="get_source"></a></p>
+
+<h3>Getting the Source</h3>
+
+<p>To get the entire set of OpenJDK Mercurial repositories use the script
+<code>get_source.sh</code> located in the root repository:</p>
- <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/jdk9/jdk9
- <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>
+<pre><code> hg clone http://hg.openjdk.java.net/jdk9/jdk9 YourOpenJDK
+ cd YourOpenJDK
+ bash ./get_source.sh
+</code></pre>
+
+<p>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.</p>
+
+<pre><code> cd YourOpenJDK
+ bash ./make/scripts/hgforest.sh status
+</code></pre>
+
+<p><a name="repositories"></a></p>
+
+<h3>Repositories</h3>
+
+<p>The set of repositories and what they contain:</p>
- <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>
+<ul>
+<li><strong>. (root)</strong> contains common configure and makefile logic</li>
+<li><strong>hotspot</strong> contains source code and make files for building the OpenJDK
+Hotspot Virtual Machine</li>
+<li><strong>langtools</strong> contains source code for the OpenJDK javac and language tools</li>
+<li><strong>jdk</strong> contains source code and make files for building the OpenJDK runtime
+libraries and misc files</li>
+<li><strong>jaxp</strong> contains source code for the OpenJDK JAXP functionality</li>
+<li><strong>jaxws</strong> contains source code for the OpenJDK JAX-WS functionality</li>
+<li><strong>corba</strong> contains source code for the OpenJDK Corba functionality</li>
+<li><strong>nashorn</strong> contains source code for the OpenJDK JavaScript implementation</li>
+</ul>
+
+<h3>Repository Source Guidelines</h3>
+
+<p>There are some very basic guidelines:</p>
+
+<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 <code>.hgignore</code> file in each repository must exist and should include
+<code>^build/</code>, <code>^dist/</code> and optionally any <code>nbproject/private</code> directories. <strong>It
+should NEVER</strong> include anything in the <code>src/</code> or <code>test/</code> 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 <code>javah</code> 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>
+
+<hr />
+
+<p><a name="building"></a></p>
- <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>
+<h2>Building</h2>
+
+<p>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.</p>
+
+<p>Building the OpenJDK is now done with running a <code>configure</code> script which will
+try and find and verify you have everything you need, followed by running
+<code>make</code>, e.g.</p>
+
+<blockquote>
+ <p><strong><code>bash ./configure</code></strong> <br />
+ <strong><code>make all</code></strong></p>
+</blockquote>
- </blockquote>
+<p>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.</p>
+
+<p><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 source guidelines.</p>
+
+<hr />
+
+<p><a name="setup"></a></p>
+
+<h3>System Setup</h3>
+
+<p>Before even attempting to use a system to build the OpenJDK there are some very
+basic system setups needed. For all systems:</p>
+
+<ul>
+<li><p>Be sure the GNU make utility is version 3.81 (4.0 on windows) or newer, e.g.
+run "<code>make -version</code>"</p>
- <!-- ====================================================== -->
- <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>.
+<p><a name="bootjdk"></a></p></li>
+<li><p>Install a Bootstrap JDK. All OpenJDK builds require access to a previously
+released JDK called the <em>bootstrap JDK</em> or <em>boot JDK.</em> 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.</p>
+
+<p><strong><em>Building JDK 9 requires JDK 8. JDK 9 developers should not use JDK 9 as
+the boot JDK, to ensure that JDK 9 dependencies are not introduced into the
+parts of the system that are built with JDK 8.</em></strong></p>
+
+<p>The JDK 8 binaries can be downloaded from Oracle's <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html">JDK 8 download
+site</a>.
+For build performance reasons it 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>.</p></li>
+<li><p>Ensure that GNU make, the Bootstrap JDK, and the compilers are all in your
+PATH environment variable.</p></li>
+</ul>
+
+<p>And for specific systems:</p>
- <!-- ====================================================== -->
- <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 (4.0 on
- windows) 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>
+<ul>
+<li><p><strong>Linux</strong></p>
+
+<p>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>. See <a href="#SDBE">specific system packages</a>.</p></li>
+<li><p><strong>Solaris</strong></p>
- <b><i>Building JDK 9 requires JDK 8. JDK 9
- developers should not use JDK 9 as the boot
- JDK, to ensure that JDK 9 dependencies are
- not introduced into the parts of the system
- that are built with JDK 8.</i></b>
+<p>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>. See <a href="#SDBE">specific system packages</a>.</p></li>
+<li><p><strong>Windows</strong></p>
+
+<ul>
+<li>Install one of <a href="#cygwin">CYGWIN</a> or <a href="#msys">MinGW/MSYS</a></li>
+<li>Install <a href="#vs2013">Visual Studio 2013</a></li>
+</ul></li>
+<li><p><strong>Mac OS X</strong></p>
+
+<p>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"</p></li>
+</ul>
- <br> <br>
- The JDK 8 binaries can be downloaded from Oracle's
- <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html"
- target="_blank">JDK 8 download site</a>.
- For build performance reasons it
- 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="#vs2013">Visual Studio 2013</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>
+<p><a name="linux"></a></p>
+
+<h4>Linux</h4>
+
+<p>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.</p>
+
+<p>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.</p>
- <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.
+<p><a name="solaris"></a></p>
+
+<h4>Solaris</h4>
+
+<p><a name="studio"></a></p>
- </blockquote>
+<h5>Studio Compilers</h5>
+
+<p>At a minimum, the <a href="http://www.oracle.com/
+technetwork/server-storage/solarisstudio/downloads/index.htm">Studio 12 Update 1 Compilers</a> (containing
+version 5.10 of the C and C++ compilers) is required, including specific
+patches.</p>
+
+<p>The Solaris SPARC patch list is:</p>
- <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>
+<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:</p>
+
+<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>
- </blockquote> <!-- Solaris -->
+<p>Place the <code>bin</code> directory in <code>PATH</code>.</p>
- <h4><a name="windows">Windows</a></h4>
- <blockquote>
+<p>The Oracle Solaris Studio Express compilers at: <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/
+downloads/index-jsp-142582.html">Oracle Solaris Studio Express
+Download site</a> are also an option, although these compilers
+have not been extensively used yet.</p>
+
+<p><a name="windows"></a></p>
+
+<h4>Windows</h4>
+
+<h5>Windows Unix Toolkit</h5>
- <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>.
+<p>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>.</p>
+
+<p><a name="cygwin"></a></p>
+
+<h6>CYGWIN</h6>
- <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>
+<p>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>
+
+<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 "<path>"</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">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.</p>
- <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>
+<blockquote>
+ <p><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></p>
+</blockquote>
- <h5><a name="vs2013">Visual Studio 2013 Compilers</a></h5>
- <blockquote>
- <p>
- The 32-bit and 64-bit OpenJDK Windows build requires
- Microsoft Visual Studio C++ 2013 (VS2013) Professional
- Edition or Express compiler.
- The compiler and other tools are expected to reside
- in the location defined by the variable
- <code>VS120COMNTOOLS</code> which
- is set by the Microsoft Visual Studio installer.
- </p>
- <p>
- Only the C++ part of VS2013 is needed.
- Try to let the installation go to the default
- install directory.
- Always reboot your system after installing VS2013.
- The system environment variable VS120COMNTOOLS
- 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>
+<p>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">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">BLODA (applications that interfere with
+CYGWIN)</a>.</p>
+
+<p><a name="msys"></a></p>
+
+<h6>MinGW/MSYS</h6>
+
+<p>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">MinGW/MSYS</a> for more information.</p>
-
- </blockquote> <!-- Windows -->
+<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>
- <h4><a name="macosx">Mac OS X</a></h4>
- <blockquote>
- Make sure you get the right XCode version.
- </blockquote> <!-- Mac OS X -->
+<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:</p>
- </blockquote>
+<pre><code> mingw-get.exe install msys-zip
+ mingw-get.exe install msys-unzip
+</code></pre>
- <!-- ====================================================== -->
- <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>
+<p><a name="vs2013"></a></p>
+
+<h5>Visual Studio 2013 Compilers</h5>
+
+<p>The 32-bit and 64-bit OpenJDK Windows build requires Microsoft Visual Studio
+C++ 2013 (VS2013) Professional Edition or Express compiler. The compiler and
+other tools are expected to reside in the location defined by the variable
+<code>VS120COMNTOOLS</code> which is set by the Microsoft Visual Studio installer.</p>
+
+<p>Only the C++ part of VS2013 is needed. Try to let the installation go to the
+default install directory. Always reboot your system after installing VS2013.
+The system environment variable VS120COMNTOOLS 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>
- <!-- ====================================================== -->
- <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.
+<p><a name="macosx"></a></p>
+
+<h4>Mac OS X</h4>
+
+<p>Make sure you get the right XCode version.</p>
+
+<hr />
+
+<p><a name="configure"></a></p>
- You can generate any number of different configurations,
- e.g. debug, release, 32, 64, etc.
+<h3>Configure</h3>
+
+<p>The basic invocation of the <code>configure</code> script looks like:</p>
- Some of the more commonly used <code>configure</code> options are:
+<blockquote>
+ <p><strong><code>bash ./configure [options]</code></strong></p>
+</blockquote>
+
+<p>This will create an output directory containing the "configuration" and setup
+an area for the build result. This directory typically looks like:</p>
- <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 2013.
- </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>
+ <p><strong><code>build/linux-x64-normal-server-release</code></strong></p>
+</blockquote>
+
+<p><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>
+
+<p>Some examples:</p>
+
+<blockquote>
+ <p><strong>Windows 32bit build with freetype specified:</strong> <br />
+ <code>bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-
+bits=32</code></p>
+
+<p><strong>Debug 64bit Build:</strong> <br />
+ <code>bash ./configure --enable-debug --with-target-bits=64</code></p>
+</blockquote>
+
+<p><a name="configureoptions"></a></p>
+
+<h4>Configure Options</h4>
+
+<p>Complete details on all the OpenJDK <code>configure</code> options can be seen with:</p>
+
+<blockquote>
+ <p><strong><code>bash ./configure --help=short</code></strong></p>
+</blockquote>
+
+<p>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.</p>
+
+<p>Some of the more commonly used <code>configure</code> options are:</p>
+
+<blockquote>
+ <p><strong><code>--enable-debug</code></strong> <br />
+ set the debug level to fastdebug (this is a shorthand for <code>--with-debug-
+ level=fastdebug</code>)</p>
+</blockquote>
+
+<p><a name="alsa"></a></p>
+
+<blockquote>
+ <p><strong><code>--with-alsa=</code></strong><em>path</em> <br />
+ select the location of the Advanced Linux Sound Architecture (ALSA)</p>
+
+<p>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.</p>
+
+<p><strong><code>--with-boot-jdk=</code></strong><em>path</em> <br />
+ select the <a href="#bootjdk">Bootstrap JDK</a></p>
+
+<p><strong><code>--with-boot-jdk-jvmargs=</code></strong>"<em>args</em>" <br />
+ provide the JVM options to be used to run the <a href="#bootjdk">Bootstrap JDK</a></p>
+
+<p><strong><code>--with-cacerts=</code></strong><em>path</em> <br />
+ select the path to the cacerts file.</p>
+
+<p>See <a href="http://en.wikipedia.org/wiki/
+ Certificate_Authority">Certificate Authority on Wikipedia</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.</p>
+</blockquote>
+
+<p><a name="cups"></a></p>
+
+<blockquote>
+ <p><strong><code>--with-cups=</code></strong><em>path</em> <br />
+ select the CUPS install location</p>
+
+<p>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 <strong>SFWcups</strong> from the Solaris Software Companion
+ CD/DVD, these often will be installed into the directory <code>/opt/sfw/cups</code>.</p>
- </blockquote>
+<p>The CUPS header files can always be downloaded from
+ <a href="http://www.cups.org">www.cups.org</a>.</p>
+
+<p><strong><code>--with-cups-include=</code></strong><em>path</em> <br />
+ select the CUPS include directory location</p>
+
+<p><strong><code>--with-debug-level=</code></strong><em>level</em> <br />
+ select the debug information level of release, fastdebug, or slowdebug</p>
+
+<p><strong><code>--with-dev-kit=</code></strong><em>path</em> <br />
+ select location of the compiler install or developer install location</p>
+</blockquote>
+
+<p><a name="freetype"></a></p>
+
+<blockquote>
+ <p><strong><code>--with-freetype=</code></strong><em>path</em> <br />
+ select the freetype files to use.</p>
- <!-- ====================================================== -->
- <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>
+<p>Expecting the freetype libraries under <code>lib/</code> and the headers under
+ <code>include/</code>.</p>
+
+<p>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.</p>
+
+<p>You can always download latest FreeType version from the <a href="http://www.freetype.org">FreeType
+ website</a>. 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>.</p>
+
+<p>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
+ <a href="http://freetype.sourceforge.net/freetype2">SourceForge FreeType2 Home Page</a>
+ for more information.</p>
+
+<p><strong><code>--with-import-hotspot=</code></strong><em>path</em> <br />
+ select the location to find hotspot binaries from a previous build to avoid
+ building hotspot</p>
- <!-- ====================================================== -->
- <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>
+<p><strong><code>--with-target-bits=</code></strong><em>arg</em> <br />
+ select 32 or 64 bit build</p>
+
+<p><strong><code>--with-jvm-variants=</code></strong><em>variants</em> <br />
+ select the JVM variants to build from, comma separated list that can
+ include: server, client, kernel, zero and zeroshark</p>
+
+<p><strong><code>--with-memory-size=</code></strong><em>size</em> <br />
+ select the RAM size that GNU make will think this system has</p>
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
- <!-- ====================================================== -->
+<p><strong><code>--with-msvcr-dll=</code></strong><em>path</em> <br />
+ select the <code>msvcr100.dll</code> file to include in the Windows builds (C/C++
+ runtime library for Visual Studio).</p>
- <!-- ====================================================== -->
- <hr>
- <h2><a name="hints">Appendix A: Hints and Tips</a></h2>
- <blockquote>
+<p>This is usually picked up automatically from the redist directories of
+ Visual Studio 2013.</p>
- <h3><a name="faq">FAQ</a></h3>
- <blockquote>
+<p><strong><code>--with-num-cores=</code></strong><em>cores</em> <br />
+ select the number of cores to use (processor count or CPU count)</p>
+</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><a name="xrender"></a></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>
+<blockquote>
+ <p><strong><code>--with-x=</code></strong><em>path</em> <br />
+ select the location of the X11 and xrender files.</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>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 <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></p>
+</blockquote>
- <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>
+<hr />
+
+<p><a name="make"></a></p>
+
+<h3>Make</h3>
+
+<p>The basic invocation of the <code>make</code> utility looks like:</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>
+<blockquote>
+ <p><strong><code>make all</code></strong></p>
+</blockquote>
+
+<p>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.</p>
+
+<p>There are some of the make targets that are of general interest:</p>
+
+<blockquote>
+ <p><em>empty</em> <br />
+ build everything but no images</p>
+
+<p><strong><code>all</code></strong> <br />
+ build everything including images</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><strong><code>all-conf</code></strong> <br />
+ build all configurations</p>
+
+<p><strong><code>images</code></strong> <br />
+ create complete j2sdk and j2re images</p>
+
+<p><strong><code>install</code></strong> <br />
+ install the generated images locally, typically in <code>/usr/local</code></p>
- <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><strong><code>clean</code></strong> <br />
+ remove all files generated by make, but not those generated by <code>configure</code></p>
+
+<p><strong><code>dist-clean</code></strong> <br />
+ remove all files generated by both and <code>configure</code> (basically killing the
+ configuration)</p>
+
+<p><strong><code>help</code></strong> <br />
+ give some help on using <code>make</code>, including some interesting make targets</p>
+</blockquote>
+
+<hr />
- <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><a name="testing"></a></p>
+
+<h2>Testing</h2>
- <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>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/*/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/">the jtreg
+site</a>. The provided regression tests in the
+repositories can be run with the command:</p>
+
+<blockquote>
+ <p><strong><code>cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all</code></strong></p>
+</blockquote>
+
+<hr />
- <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><a name="hints"></a></p>
+
+<h2>Appendix A: Hints and Tips</h2>
+
+<p><a name="faq"></a></p>
+
+<h3>FAQ</h3>
- <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><strong>Q:</strong> The <code>generated-configure.sh</code> file looks horrible! How are you going to
+edit it? <br />
+<strong>A:</strong> 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>
- 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><strong>Q:</strong> Why is the <code>generated-configure.sh</code> file checked in, if it is
+generated? <br />
+<strong>A:</strong> 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>
- 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><strong>Q:</strong> Do you require a specific version of autoconf for regenerating
+<code>generated-configure.sh</code>? <br />
+<strong>A:</strong> 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><strong>Q:</strong> How do you regenerate <code>generated-configure.sh</code> after making changes to
+the input files? <br />
+<strong>A:</strong> 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>
- 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><strong>Q:</strong> What are the files in <code>common/makefiles/support/*</code> for? They look like
+gibberish. <br />
+<strong>A:</strong> 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 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>
+<p><strong>Q:</strong> I want to see the output of the commands that make runs, like in the old
+build. How do I do that? <br />
+<strong>A:</strong> You specify the <code>LOG</code> variable to make. There are several log levels:</p>
- </blockquote>
-
- <h3><a name="performance">Build Performance Tips</a></h3>
- <blockquote>
+<ul>
+<li><strong><code>warn</code></strong> -- Default and very quiet.</li>
+<li><strong><code>info</code></strong> -- Shows more progress information than warn.</li>
+<li><strong><code>debug</code></strong> -- Echos all command lines and prints all macro calls for
+compilation definitions.</li>
+<li><strong><code>trace</code></strong> -- Echos all $(shell) command lines as well.</li>
+</ul>
- <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>
+<p><strong>Q:</strong> When do I have to re-run <code>configure</code>? <br />
+<strong>A:</strong> 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>
- <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><strong>Q:</strong> I have added a new source file. Do I need to modify the makefiles? <br />
+<strong>A:</strong> 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>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><strong>Q:</strong> When I run <code>configure --help</code>, I see many strange options, like
+<code>--dvidir</code>. What is this? <br />
+<strong>A:</strong> 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>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 fully supported.</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><strong>Q:</strong> <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 />
+<strong>A:</strong> 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>The OpenJDK build supports building with ccache
- when using gcc or clang. Using ccache can
- radically speed up compilation of native code if
- you often rebuild the same sources. Your milage
- may vary however so we recommend evaluating it for
- yourself. To enable it, make sure it's on the path
- and configure with <code>--enable-ccache</code>.</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><strong>Q:</strong> How will you make sure you don't break anything? <br />
+<strong>A:</strong> 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>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><strong>Q:</strong> I noticed this thing X in the build that looks very broken by design.
+Why don't you fix it? <br />
+<strong>A:</strong> 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>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>
+<p><strong>Q:</strong> The code in the new build system is not that well-structured. Will you
+fix this? <br />
+<strong>A:</strong> 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>
- <h3><a name="troubleshooting">Troubleshooting</a></h3>
- <blockquote>
+<p><strong>Q:</strong> Is anything able to use the results of the new build's default make
+target? <br />
+<strong>A:</strong> 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><strong>Q:</strong> 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 />
+<strong>A:</strong> 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>
+
+<p><a name="performance"></a></p>
+
+<h3>Build Performance Tips</h3>
+
+<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><strong><code>--with-num-cores</code></strong> -- number of cores in the build system, e.g.
+<code>--with-num-cores=8</code></li>
+<li><strong><code>--with-memory-size</code></strong> -- 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 fully supported.</p>
- <h4>Solving build problems</h4>
+<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>The OpenJDK build supports building with ccache when using gcc or clang. Using
+ccache can radically speed up compilation of native code if you often rebuild
+the same sources. Your milage may vary however so we recommend evaluating it
+for yourself. To enable it, make sure it's on the path and configure with
+<code>--enable-ccache</code>.</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>
- 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>
+<p><a name="troubleshooting"></a></p>
+
+<h3>Troubleshooting</h3>
+
+<h4>Solving build problems</h4>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>Some of the more common problems with builds are briefly described below, with
+suggestions for remedies.</p>
+
+<ul>
+<li><p><strong>Corrupted Bundles on Windows:</strong> <br />
+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.</p></li>
+<li><p><strong>Slow Builds:</strong> <br />
+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:</p>
+
+<p>Creating the javadocs can be very slow, if you are running javadoc, consider
+skipping that step.</p>
- </blockquote> <!-- Troubleshooting -->
+<p>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.</p>
- </blockquote> <!-- Appendix A -->
+<p>Faster compiles are possible using a tool called
+<a href="http://ccache.samba.org/">ccache</a>.</p></li>
+<li><p><strong>File time issues:</strong> <br />
+If you see warnings that refer to file time stamps, e.g.</p>
- <!-- ====================================================== -->
- <hr>
- <h2><a name="gmake">Appendix B: GNU make</a></h2>
- <blockquote>
+<blockquote>
+ <p><em>Warning message:</em> <code>File 'xxx' has modification time in the future.</code> <br />
+<em>Warning message:</em> <code>Clock skew detected. Your build may be incomplete.</code></p>
+</blockquote>
+
+<p>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>
- 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. On Windows 4.0 or
- newer is recommended.
- If the GNU make utility on your systems is not of a suitable
- version 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>
+<p>If you see these warnings, reset the clock on the build machine, run
+"<code>gmake clobber</code>" or delete the directory containing the build output, and
+restart the build from the beginning.</p></li>
+<li><p><strong>Error message: <code>Trouble writing out table to disk</code></strong> <br />
+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:</p>
+
+<blockquote>
+ <p><code>make JOBS=1</code></p>
+</blockquote>
- <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>
+<p>to reduce the load on the system.</p></li>
+<li><p><strong>Error Message: <code>libstdc++ not found</code>:</strong> <br />
+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.</p></li>
+<li><p><strong>Linux Error Message: <code>cannot restore segment prot after reloc</code></strong> <br />
+This is probably an issue with SELinux (See <a href="http://en.wikipedia.org/wiki/SELinux">SELinux on
+Wikipedia</a>). Parts of the VM is built
+without the <code>-fPIC</code> for performance reasons.</p>
- </blockquote> <!-- Appendix B -->
-
- <!-- ====================================================== -->
- <hr>
- <h2><a name="buildenvironments">Appendix C: Build Environments</a></h2>
- <blockquote>
+<p>To completely disable SELinux:</p>
- <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>Oracle Enterprise Linux 6.4</td>
- <td>gcc 4.8.2 </td>
- <td>JDK 8</td>
- <td>2 or more</td>
- <td>1 GB</td>
- <td>6 GB</td>
- </tr>
- <tr>
- <td>Solaris SPARCV9 (64-bit)</td>
- <td>Solaris 10 Update 10</td>
- <td>Studio 12 Update 3 + patches</td>
- <td>JDK 8</td>
- <td>4 or more</td>
- <td>4 GB</td>
- <td>8 GB</td>
- </tr>
- <tr>
- <td>Solaris X64 (64-bit)</td>
- <td>Solaris 10 Update 10</td>
- <td>Studio 12 Update 3 + patches</td>
- <td>JDK 8</td>
- <td>4 or more</td>
- <td>4 GB</td>
- <td>8 GB</td>
- </tr>
- <tr>
- <td>Windows X86 (32-bit)</td>
- <td>Windows Server 2012 R2 x64</td>
- <td>Microsoft Visual Studio C++ 2013 Professional Edition</td>
- <td>JDK 8</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 2012 R2 x64</td>
- <td>Microsoft Visual Studio C++ 2013 Professional Edition</td>
- <td>JDK 8</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.9 "Mavericks"</td>
- <td>XCode 5.1.1 or newer</td>
- <td>JDK 8</td>
- <td>2 or more</td>
- <td>4 GB</td>
- <td>6 GB</td>
- </tr>
- </tbody>
- </table>
- </blockquote>
+<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.</p>
+
+<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></li>
+<li><p><strong>Windows Error Messages:</strong> <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></p>
- <!-- ====================================================== -->
- <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>
+<p>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">BLODA (applications that interfere with
+CYGWIN)</a>.</p></li>
+<li><p><strong>Windows Error Message: <code>spawn failed</code></strong> <br />
+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.</p></li>
+</ul>
+
+<hr />
+
+<p><a name="gmake"></a></p>
+
+<h2>Appendix B: GNU make</h2>
- <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>
+<p>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:</p>
+<ul>
+<li>You need GNU make version 3.81 or newer. On Windows 4.0 or newer is
+recommended. If the GNU make utility on your systems is not of a suitable
+version, 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">GNU make web site </a>. The latest
+source to GNU make is available at
+<a href="http://ftp.gnu.org/pub/gnu/make/">ftp.gnu.org/pub/gnu/make/</a>.</p>
- <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>
+<p><a name="buildgmake"></a></p>
+
+<h3>Building GNU make</h3>
+
+<p>First step is to get the GNU make 3.81 or newer source from
+<a href="http://ftp.gnu.org/pub/gnu/make/">ftp.gnu.org/pub/gnu/make/</a>. Building is a
+little different depending on the OS but is basically done with:</p>
+
+<pre><code> bash ./configure
+ make
+</code></pre>
+
+<hr />
- <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>
+<p><a name="buildenvironments"></a></p>
+
+<h2>Appendix C: Build Environments</h2>
+
+<h3>Minimum Build Environments</h3>
+
+<p>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>
- <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>
+<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>
- <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>
+<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>
+
+<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.</p>
+
+<p><strong>NOTE: We expect a change here off these older Windows OS releases and to a
+'less older' one, probably Windows 2008R2 X64.</strong></p>
- <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>
+<p>With Linux, it was just a matter of picking a stable distribution that is a
+good representative for Linux in general.</p>
+
+<p><strong>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.</strong></p>
- <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>
+<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>
- </blockquote>
-
- </blockquote> <!-- Appendix C -->
+<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>
- <!-- ====================================================== -->
-
- <!-- 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>
+ <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>Oracle Enterprise Linux 6.4</td>
+ <td>gcc 4.8.2 </td>
+ <td>JDK 8</td>
+ <td>2 or more</td>
+ <td>1 GB</td>
+ <td>6 GB</td>
+ </tr>
+ <tr>
+ <td>Solaris SPARCV9 (64-bit)</td>
+ <td>Solaris 10 Update 10</td>
+ <td>Studio 12 Update 3 + patches</td>
+ <td>JDK 8</td>
+ <td>4 or more</td>
+ <td>4 GB</td>
+ <td>8 GB</td>
+ </tr>
+ <tr>
+ <td>Solaris X64 (64-bit)</td>
+ <td>Solaris 10 Update 10</td>
+ <td>Studio 12 Update 3 + patches</td>
+ <td>JDK 8</td>
+ <td>4 or more</td>
+ <td>4 GB</td>
+ <td>8 GB</td>
+ </tr>
+ <tr>
+ <td>Windows X86 (32-bit)</td>
+ <td>Windows Server 2012 R2 x64</td>
+ <td>Microsoft Visual Studio C++ 2013 Professional Edition</td>
+ <td>JDK 8</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 2012 R2 x64</td>
+ <td>Microsoft Visual Studio C++ 2013 Professional Edition</td>
+ <td>JDK 8</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.9 "Mavericks"</td>
+ <td>XCode 5.1.1 or newer</td>
+ <td>JDK 8</td>
+ <td>2 or more</td>
+ <td>4 GB</td>
+ <td>6 GB</td>
+ </tr>
+ </tbody>
+ </table></p>
+</blockquote>
+
+<hr />
+
+<p><a name="SDBE"></a></p>
+
+<h3>Specific Developer Build Environments</h3>
+
+<p>We won't be listing all the possible environments, but we will try to provide
+what information we have available to us.</p>
+
+<p><strong>NOTE: The community can help out by updating this part of the document.</strong></p>
+
+<h4>Fedora</h4>
+
+<p>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>:</p>
+
+<pre><code> yum-builddep java-1.7.0-openjdk
+ yum install gcc gcc-c++
+</code></pre>
+
+<p>In addition, it's necessary to set a few environment variables for the build:</p>
+
+<pre><code> export LANG=C
+ export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}"
+</code></pre>
+
+<h4>CentOS 5.5</h4>
+
+<p>After installing <a href="http://www.centos.org/">CentOS 5.5</a> you need to make sure you
+have the following Development bundles installed:</p>
+
+<ul>
+<li>Development Libraries</li>
+<li>Development Tools</li>
+<li>Java Development</li>
+<li>X Software Development (Including XFree86-devel)</li>
+</ul>
+
+<p>Plus the following packages:</p>
- <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>
+<ul>
+<li>cups devel: Cups Development Package</li>
+<li>alsa devel: Alsa Development Package</li>
+<li>Xi devel: libXi.so Development Package</li>
+</ul>
+
+<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:</p>
+
+<pre><code> bash ./configure
+ make
+ sudo -u root make install
+</code></pre>
+
+<p>Mercurial packages could not be found easily, but a Google search should find
+ones, and they usually include Python if it's needed.</p>
+
+<h4>Debian 5.0 (Lenny)</h4>
+
+<p>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>:</p>
+
+<pre><code> aptitude build-dep openjdk-7
+ aptitude install openjdk-7-jdk libmotif-dev
+</code></pre>
+
+<p>In addition, it's necessary to set a few environment variables for the build:</p>
+
+<pre><code> export LANG=C
+ export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"
+</code></pre>
+
+<h4>Ubuntu 12.04</h4>
+
+<p>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:</p>
+
+<pre><code> sudo aptitude build-dep openjdk-7
+ sudo aptitude install openjdk-7-jdk
+</code></pre>
+
+<p>In addition, it's necessary to set a few environment variables for the build:</p>
+
+<pre><code> export LANG=C
+ export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"
+</code></pre>
+
+<h4>OpenSUSE 11.1</h4>
- <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>
+<p>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:</p>
+
+<pre><code> sudo zypper source-install -d java-1_7_0-openjdk
+ sudo zypper install make
+</code></pre>
+
+<p>In addition, it is necessary to set a few environment variables for the build:</p>
+
+<pre><code> export LANG=C
+ export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}"
+</code></pre>
+
+<p>Finally, you need to unset the <code>JAVA_HOME</code> environment variable:</p>
+
+<pre><code> export -n JAVA_HOME`
+</code></pre>
+
+<h4>Mandriva Linux One 2009 Spring</h4>
+
+<p>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>:</p>
+
+<pre><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></pre>
-</blockquote> <!-- Appendix D -->
+<p>In addition, it is necessary to set a few environment variables for the build:</p>
+
+<pre><code> export LANG=C
+ export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}"
+</code></pre>
+
+<h4>OpenSolaris 2009.06</h4>
+
+<p>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:</p>
- <!-- ====================================================== -->
- <hr>
- <p>End of OpenJDK README-builds.html document.<br>Please come again!
- <hr>
+<pre><code> pfexec pkg install SUNWgmake SUNWj7dev sunstudioexpress SUNWcups SUNWzip
+ SUNWunzip SUNWxwhl SUNWxorg-headers SUNWaudh SUNWfreetype2
+</code></pre>
+
+<p>In addition, it is necessary to set a few environment variables for the build:</p>
- </body>
+<pre><code> export LANG=C
+ export PATH="/opt/SunStudioExpress/bin:${PATH}"
+</code></pre>
+
+<hr />
+
+<p>End of the OpenJDK build README document.</p>
+
+<p>Please come again!</p>
+ </body>
</html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/README-builds.md Thu Oct 22 11:12:30 2015 -0700
@@ -0,0 +1,1263 @@
+
+# OpenJDK Build README
+
+*****
+
+<a name="introduction"></a>
+## Introduction
+
+This README file contains build instructions for the
+[OpenJDK](http://openjdk.java.net). 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, except on Windows where 4.0 or newer
+ is recommended.
+ * 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*.bat` and `vcvars*.bat` files 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
+
+*****
+
+## Contents
+
+ * [Introduction](#introduction)
+ * [Use of Mercurial](#hg)
+ * [Getting the Source](#get_source)
+ * [Repositories](#repositories)
+ * [Building](#building)
+ * [System Setup](#setup)
+ * [Linux](#linux)
+ * [Solaris](#solaris)
+ * [Mac OS X](#macosx)
+ * [Windows](#windows)
+ * [Configure](#configure)
+ * [Make](#make)
+ * [Testing](#testing)
+
+*****
+
+ * [Appendix A: Hints and Tips](#hints)
+ * [FAQ](#faq)
+ * [Build Performance Tips](#performance)
+ * [Troubleshooting](#troubleshooting)
+ * [Appendix B: GNU Make Information](#gmake)
+ * [Appendix C: Build Environments](#buildenvironments)
+
+*****
+
+<a name="hg"></a>
+## Use of Mercurial
+
+The OpenJDK sources are maintained with the revision control system
+[Mercurial](http://mercurial.selenic.com/wiki/Mercurial). If you are new to
+Mercurial, please see the [Beginner Guides](http://mercurial.selenic.com/wiki/
+BeginnersGuides) or refer to the [Mercurial Book](http://hgbook.red-bean.com/).
+The first few chapters of the book provide an excellent overview of Mercurial,
+what it is and how it works.
+
+For using Mercurial with the OpenJDK refer to the [Developer Guide: Installing
+and Configuring Mercurial](http://openjdk.java.net/guide/
+repositories.html#installConfig) section for more information.
+
+<a name="get_source"></a>
+### Getting the Source
+
+To get the entire set of OpenJDK Mercurial repositories use the script
+`get_source.sh` located in the root repository:
+
+ hg clone http://hg.openjdk.java.net/jdk9/jdk9 YourOpenJDK
+ cd YourOpenJDK
+ bash ./get_source.sh
+
+Once you have all the repositories, keep in mind that each repository is its
+own independent repository. You can also re-run `./get_source.sh` 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 `hg` command to each of the repositories. For
+example, the script `make/scripts/hgforest.sh` can be used to repeat the
+same `hg` command on every repository, e.g.
+
+ cd YourOpenJDK
+ bash ./make/scripts/hgforest.sh status
+
+<a name="repositories"></a>
+### Repositories
+
+The set of repositories and what they contain:
+
+ * **. (root)** contains common configure and makefile logic
+ * **hotspot** contains source code and make files for building the OpenJDK
+ Hotspot Virtual Machine
+ * **langtools** contains source code for the OpenJDK javac and language tools
+ * **jdk** contains source code and make files for building the OpenJDK runtime
+ libraries and misc files
+ * **jaxp** contains source code for the OpenJDK JAXP functionality
+ * **jaxws** contains source code for the OpenJDK JAX-WS functionality
+ * **corba** contains source code for the OpenJDK Corba functionality
+ * **nashorn** contains source code for the OpenJDK JavaScript implementation
+
+### 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.
+
+*****
+
+<a name="building"></a>
+## Building
+
+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.
+
+> **`bash ./configure`**
+> **`make all`**
+
+Where possible the `configure` 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 `configure` options may be necessary to help `configure` 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:** The `configure` script file does not have execute permissions and
+will need to be explicitly run with `bash`, see the source guidelines.
+
+*****
+
+<a name="setup"></a>
+### System Setup
+
+Before even attempting to use a system to build the OpenJDK there are some very
+basic system setups needed. For all systems:
+
+ * Be sure the GNU make utility is version 3.81 (4.0 on windows) or newer, e.g.
+ run "`make -version`"
+
+ <a name="bootjdk"></a>
+ * Install a Bootstrap JDK. All OpenJDK builds require access to a previously
+ released JDK called the _bootstrap JDK_ or _boot JDK._ 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.
+
+ **_Building JDK 9 requires JDK 8. JDK 9 developers should not use JDK 9 as
+ the boot JDK, to ensure that JDK 9 dependencies are not introduced into the
+ parts of the system that are built with JDK 8._**
+
+ The JDK 8 binaries can be downloaded from Oracle's [JDK 8 download
+ site](http://www.oracle.com/technetwork/java/javase/downloads/index.html).
+ For build performance reasons it is very important that this bootstrap JDK
+ be made available on the local disk of the machine doing the build. You
+ should add its `bin` directory to the `PATH` environment variable. If
+ `configure` has any issues finding this JDK, you may need to use the
+ `configure` option `--with-boot-jdk`.
+
+ * Ensure that GNU make, the Bootstrap JDK, and the compilers are all in your
+ PATH environment variable.
+
+And for specific systems:
+
+ * **Linux**
+
+ Install all the software development packages needed including
+ [alsa](#alsa), [freetype](#freetype), [cups](#cups), and
+ [xrender](#xrender). See [specific system packages](#SDBE).
+
+ * **Solaris**
+
+ Install all the software development packages needed including [Studio
+ Compilers](#studio), [freetype](#freetype), [cups](#cups), and
+ [xrender](#xrender). See [specific system packages](#SDBE).
+
+ * **Windows**
+
+ * Install one of [CYGWIN](#cygwin) or [MinGW/MSYS](#msys)
+ * Install [Visual Studio 2013](#vs2013)
+
+ * **Mac OS X**
+
+ Install [XCode 4.5.2](https://developer.apple.com/xcode/) and also
+ install the "Command line tools" found under the preferences pane
+ "Downloads"
+
+<a name="linux"></a>
+#### 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 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.
+
+<a name="solaris"></a>
+#### Solaris
+
+<a name="studio"></a>
+##### Studio Compilers
+
+At a minimum, the [Studio 12 Update 1 Compilers](http://www.oracle.com/
+technetwork/server-storage/solarisstudio/downloads/index.htm) (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 `bin` directory in `PATH`.
+
+The Oracle Solaris Studio Express compilers at: [Oracle Solaris Studio Express
+Download site](http://www.oracle.com/technetwork/server-storage/solarisstudio/
+downloads/index-jsp-142582.html) are also an option, although these compilers
+have not been extensively used yet.
+
+<a name="windows"></a>
+#### 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](http://www.cygwin.com/) and
+[MinGW/MSYS](http://www.mingw.org/wiki/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](http://en.wikipedia.org/wiki/8.3_filename).
+
+<a name="cygwin"></a>
+###### 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 `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`](#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.
+
+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](http://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.
+
+> <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>
+
+Note that the CYGWIN software can conflict with other non-CYGWIN software on
+your Windows system. CYGWIN provides a [FAQ](http://cygwin.com/faq/
+faq.using.html) for known issues and problems, of particular interest is the
+section on [BLODA (applications that interfere with
+CYGWIN)](http://cygwin.com/faq/faq.using.html#faq.using.bloda).
+
+<a name="msys"></a>
+###### 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`. See [MinGW/MSYS](http://www.mingw.org/
+wiki/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](http://mingw.org/wiki/
+Posix_path_conversion).
+
+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
+
+<a name="vs2013"></a>
+##### Visual Studio 2013 Compilers
+
+The 32-bit and 64-bit OpenJDK Windows build requires Microsoft Visual Studio
+C++ 2013 (VS2013) Professional Edition or Express compiler. The compiler and
+other tools are expected to reside in the location defined by the variable
+`VS120COMNTOOLS` which is set by the Microsoft Visual Studio installer.
+
+Only the C++ part of VS2013 is needed. Try to let the installation go to the
+default install directory. Always reboot your system after installing VS2013.
+The system environment variable VS120COMNTOOLS 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.
+
+<a name="macosx"></a>
+#### Mac OS X
+
+Make sure you get the right XCode version.
+
+*****
+
+<a name="configure"></a>
+### Configure
+
+The basic invocation of the `configure` script looks like:
+
+> **`bash ./configure [options]`**
+
+This will create an output directory containing the "configuration" and setup
+an area for the build result. This directory typically looks like:
+
+> **`build/linux-x64-normal-server-release`**
+
+`configure` 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 [the `configure` options](#configureoptions).
+
+Some examples:
+
+> **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`
+
+<a name="configureoptions"></a>
+#### Configure Options
+
+Complete details on all the OpenJDK `configure` options can be seen with:
+
+> **`bash ./configure --help=short`**
+
+Use `-help` to see all the `configure` options available. You can generate any
+number of different configurations, e.g. debug, release, 32, 64, etc.
+
+Some of the more commonly used `configure` options are:
+
+> **`--enable-debug`**
+> set the debug level to fastdebug (this is a shorthand for `--with-debug-
+ level=fastdebug`)
+
+<a name="alsa"></a>
+> **`--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](#bootjdk)
+
+> **`--with-boot-jdk-jvmargs=`**"_args_"
+> provide the JVM options to be used to run the [Bootstrap JDK](#bootjdk)
+
+> **`--with-cacerts=`**_path_
+> select the path to the cacerts file.
+
+> See [Certificate Authority on Wikipedia](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.
+
+<a name="cups"></a>
+> **`--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](http://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
+
+<a name="freetype"></a>
+> **`--with-freetype=`**_path_
+> select the freetype files to use.
+
+> Expecting the freetype libraries under `lib/` and the headers under
+ `include/`.
+
+> 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](http://www.freetype.org). Building the freetype 2 libraries from
+ scratch is also possible, however on Windows refer to the [Windows FreeType
+ DLL build instructions](http://freetype.freedesktop.org/wiki/FreeType_DLL).
+
+> 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](http://freetype.sourceforge.net/freetype2)
+ 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 2013.
+
+> **`--with-num-cores=`**_cores_
+> select the number of cores to use (processor count or CPU count)
+
+<a name="xrender"></a>
+> **`--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.h` or
+ `/usr/openwin/share/include/X11/extensions/Xrender.h`
+
+*****
+
+<a name="make"></a>
+### Make
+
+The basic invocation of the `make` utility looks like:
+
+> **`make all`**
+
+This will start the build to the output directory containing the
+"configuration" that was created by the `configure` script. Run `make help` for
+more information on the available targets.
+
+There are some of the make targets that are of general interest:
+
+> _empty_
+> build everything but no images
+
+> **`all`**
+> build everything including images
+
+> **`all-conf`**
+> build all configurations
+
+> **`images`**
+> create complete j2sdk and j2re images
+
+> **`install`**
+> install the generated images locally, typically in `/usr/local`
+
+> **`clean`**
+> remove all files generated by make, but not those generated by `configure`
+
+> **`dist-clean`**
+> remove all files generated by both and `configure` (basically killing the
+ configuration)
+
+> **`help`**
+> give some help on using `make`, including some interesting make targets
+
+*****
+
+<a name="testing"></a>
+## Testing
+
+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 tool `jtreg` will be needed and can be found at: [the jtreg
+site](http://openjdk.java.net/jtreg/). The provided regression tests in the
+repositories can be run with the command:
+
+> **``cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all``**
+
+*****
+
+<a name="hints"></a>
+## Appendix A: Hints and Tips
+
+<a name="faq"></a>
+### FAQ
+
+**Q:** The `generated-configure.sh` file looks horrible! How are you going to
+edit it?
+**A:** The `generated-configure.sh` file is generated (think "compiled") by the
+autoconf tools. The source code is in `configure.ac` and various .m4 files in
+common/autoconf, which are much more readable.
+
+**Q:** Why is the `generated-configure.sh` file checked in, if it is
+generated?
+**A:** If it was not generated, every user would need to have the autoconf
+tools installed, and re-generate the `configure` 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.
+
+**Q:** Do you require a specific version of autoconf for regenerating
+`generated-configure.sh`?
+**A:** 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 `generated-configure.sh`.
+
+**Q:** How do you regenerate `generated-configure.sh` after making changes to
+the input files?
+**A:** Regnerating `generated-configure.sh` should always be done using the
+script `common/autoconf/autogen.sh` to ensure that the correct files get
+updated. This script should also be run after mercurial tries to merge
+`generated-configure.sh` as a merge of the generated file is not guaranteed to
+be correct.
+
+**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 the `LOG` variable to make. There are several log levels:
+
+ * **`warn`** -- Default and very quiet.
+ * **`info`** -- Shows more progress information than warn.
+ * **`debug`** -- Echos all command lines and prints all macro calls for
+ compilation definitions.
+ * **`trace`** -- Echos all $(shell) command lines as well.
+
+**Q:** When do I have to re-run `configure`?
+**A:** Normally you will run `configure` 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 `configure` script.
+
+**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 sources
+for other libraries. In these cases it was simply easier to create include
+lists rather than 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, use `configure --help=short`
+instead.
+
+**Q:** `configure` provides OpenJDK-specific features such as `--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. Others depend 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:** 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 the `images` 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 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!
+
+<a name="performance"></a>
+### 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 `configure` 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:
+
+ * **`--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 fully supported.
+
+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
+
+The OpenJDK build supports building with ccache when using gcc or clang. Using
+ccache can radically speed up compilation of native code if you often rebuild
+the same sources. Your milage may vary however so we recommend evaluating it
+for yourself. To enable it, make sure it's on the path and configure with
+`--enable-ccache`.
+
+#### 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, `configure` 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 `configure` basis) using
+`--with-num-cores=N` or for a single build only (on a make basis), using
+`make 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 even `make 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 `configure` with
+`--with-num-cores=2`, making 2 the default. If you want to run with more cores,
+run `make JOBS=8`
+
+<a name="troubleshooting"></a>
+### Troubleshooting
+
+#### Solving build problems
+
+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 `LOG=debug` to 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.log` in your build directory.
+
+You can ask for help on build problems with the new build system on either the
+[build-dev](http://mail.openjdk.java.net/mailman/listinfo/build-dev) or the
+[build-infra-dev](http://mail.openjdk.java.net/mailman/listinfo/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 the `configure` 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 `configure` had 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=1` on the `make` command 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](http://ccache.samba.org/).
+
+ * **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.`
+ > _Warning message:_ ` Clock skew detected. Your build may be incomplete.`
+
+ 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.
+
+ 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:
+
+ > `make JOBS=1`
+
+ to reduce the load on the system.
+
+ * **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 [SELinux on
+ Wikipedia](http://en.wikipedia.org/wiki/SELinux)). Parts of the VM is built
+ without the `-fPIC` for performance reasons.
+
+ To completely disable SELinux:
+
+ 1. `$ su root`
+ 2. `# system-config-securitylevel`
+ 3. `In the window that appears, select the SELinux tab`
+ 4. `Disable SELinux`
+
+ Alternatively, instead of completely disabling it you could disable just
+ this one check.
+
+ 1. Select System->Administration->SELinux Management
+ 2. In the SELinux Management Tool which appears, select "Boolean" from the
+ menu on the left
+ 3. Expand the "Memory Protection" group
+ 4. 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)](http://cygwin.com/faq/faq.using.html#faq.using.bloda).
+
+ * **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.
+
+*****
+
+<a name="gmake"></a>
+## Appendix B: GNU make
+
+The Makefiles in the OpenJDK are only valid when used with the GNU version of
+the utility command `make` (usually called `gmake` on Solaris). A few notes
+about using GNU make:
+
+ * You need GNU make version 3.81 or newer. On Windows 4.0 or newer is
+ recommended. If the GNU make utility on your systems is not of a suitable
+ version, see "[Building GNU make](#buildgmake)".
+ * Place the location of the GNU make binary in the `PATH`.
+ * **Solaris:** Do NOT use `/usr/bin/make` on Solaris. If your Solaris system
+ has the software from the Solaris Developer Companion CD installed, you
+ should try and use `gmake` which will be located in either the `/usr/bin`,
+ `/opt/sfw/bin` or `/usr/sfw/bin` directory.
+ * **Windows:** Make sure you start your build inside a bash shell.
+ * **Mac OS X:** The XCode "command line tools" must be installed on your Mac.
+
+Information on GNU make, and access to ftp download sites, are available on the
+[GNU make web site ](http://www.gnu.org/software/make/make.html). The latest
+source to GNU make is available at
+[ftp.gnu.org/pub/gnu/make/](http://ftp.gnu.org/pub/gnu/make/).
+
+<a name="buildgmake"></a>
+### Building GNU make
+
+First step is to get the GNU make 3.81 or newer source from
+[ftp.gnu.org/pub/gnu/make/](http://ftp.gnu.org/pub/gnu/make/). Building is a
+little different depending on the OS but is basically done with:
+
+ bash ./configure
+ make
+
+*****
+
+<a name="buildenvironments"></a>
+## Appendix C: Build Environments
+
+### Minimum Build Environments
+
+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/include` 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.
+
+> <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>Oracle Enterprise Linux 6.4</td>
+ <td>gcc 4.8.2 </td>
+ <td>JDK 8</td>
+ <td>2 or more</td>
+ <td>1 GB</td>
+ <td>6 GB</td>
+ </tr>
+ <tr>
+ <td>Solaris SPARCV9 (64-bit)</td>
+ <td>Solaris 10 Update 10</td>
+ <td>Studio 12 Update 3 + patches</td>
+ <td>JDK 8</td>
+ <td>4 or more</td>
+ <td>4 GB</td>
+ <td>8 GB</td>
+ </tr>
+ <tr>
+ <td>Solaris X64 (64-bit)</td>
+ <td>Solaris 10 Update 10</td>
+ <td>Studio 12 Update 3 + patches</td>
+ <td>JDK 8</td>
+ <td>4 or more</td>
+ <td>4 GB</td>
+ <td>8 GB</td>
+ </tr>
+ <tr>
+ <td>Windows X86 (32-bit)</td>
+ <td>Windows Server 2012 R2 x64</td>
+ <td>Microsoft Visual Studio C++ 2013 Professional Edition</td>
+ <td>JDK 8</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 2012 R2 x64</td>
+ <td>Microsoft Visual Studio C++ 2013 Professional Edition</td>
+ <td>JDK 8</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.9 "Mavericks"</td>
+ <td>XCode 5.1.1 or newer</td>
+ <td>JDK 8</td>
+ <td>2 or more</td>
+ <td>4 GB</td>
+ <td>6 GB</td>
+ </tr>
+ </tbody>
+ </table>
+
+*****
+
+<a name="SDBE"></a>
+### Specific Developer Build Environments
+
+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](http://fedoraproject.org) 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](http://www.centos.org/) 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](http://downloads.sourceforge.net/freetype). 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](http://debian.org) 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](http://ubuntu.org) 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](http://opensuse.org) 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](http://mandriva.org) 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](http://opensolaris.org) 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}"
+
+*****
+
+End of the OpenJDK build README document.
+
+Please come again!
--- a/common/autoconf/basics.m4 Thu Oct 22 08:47:39 2015 -0700
+++ b/common/autoconf/basics.m4 Thu Oct 22 11:12:30 2015 -0700
@@ -410,6 +410,7 @@
BASIC_REQUIRE_PROGS(NAWK, [nawk gawk awk])
BASIC_REQUIRE_PROGS(PRINTF, printf)
BASIC_REQUIRE_PROGS(RM, rm)
+ BASIC_REQUIRE_PROGS(RMDIR, rmdir)
BASIC_REQUIRE_PROGS(SH, sh)
BASIC_REQUIRE_PROGS(SORT, sort)
BASIC_REQUIRE_PROGS(TAIL, tail)
--- a/common/autoconf/boot-jdk.m4 Thu Oct 22 08:47:39 2015 -0700
+++ b/common/autoconf/boot-jdk.m4 Thu Oct 22 11:12:30 2015 -0700
@@ -305,6 +305,16 @@
BOOT_JDK_SOURCETARGET="-source 8 -target 8"
AC_SUBST(BOOT_JDK_SOURCETARGET)
AC_SUBST(JAVAC_FLAGS)
+
+ # Check if the boot jdk is 32 or 64 bit
+ if "$JAVA" -d64 -version > /dev/null 2>&1; then
+ BOOT_JDK_BITS="64"
+ else
+ BOOT_JDK_BITS="32"
+ fi
+ AC_MSG_CHECKING([if Boot JDK is 32 or 64 bits])
+ AC_MSG_RESULT([$BOOT_JDK_BITS])
+ AC_SUBST(BOOT_JDK_BITS)
])
AC_DEFUN_ONCE([BOOTJDK_SETUP_BOOT_JDK_ARGUMENTS],
@@ -341,7 +351,7 @@
# Maximum amount of heap memory.
# Maximum stack size.
JVM_MAX_HEAP=`expr $MEMORY_SIZE / 2`
- if test "x$BUILD_NUM_BITS" = x32; then
+ if test "x$BOOT_JDK_BITS" = "x32"; then
if test "$JVM_MAX_HEAP" -gt "1100"; then
JVM_MAX_HEAP=1100
elif test "$JVM_MAX_HEAP" -lt "512"; then
@@ -349,10 +359,7 @@
fi
STACK_SIZE=768
else
- # Running Javac on a JVM on a 64-bit machine, takes more space since 64-bit
- # pointers are used. Apparently, we need to increase the heap and stack
- # space for the jvm. More specifically, when running javac to build huge
- # jdk batch
+ # Running a 64 bit JVM allows for and requires a bigger heap
if test "$JVM_MAX_HEAP" -gt "1600"; then
JVM_MAX_HEAP=1600
elif test "$JVM_MAX_HEAP" -lt "512"; then
--- a/common/autoconf/compare.sh.in Thu Oct 22 08:47:39 2015 -0700
+++ b/common/autoconf/compare.sh.in Thu Oct 22 11:12:30 2015 -0700
@@ -66,7 +66,7 @@
export TEE="@TEE@"
export UNIQ="@UNIQ@"
export UNPACK200="@FIXPATH@ @BOOT_JDK@/bin/unpack200"
-export UNZIP="@UNZIP@"
+export UNARCHIVE="@UNZIP@ -q"
export SRC_ROOT="@TOPDIR@"
export OUTPUT_ROOT="@OUTPUT_ROOT@"
--- a/common/autoconf/generated-configure.sh Thu Oct 22 08:47:39 2015 -0700
+++ b/common/autoconf/generated-configure.sh Thu Oct 22 11:12:30 2015 -0700
@@ -815,6 +815,7 @@
JAXP_TOPDIR
CORBA_TOPDIR
LANGTOOLS_TOPDIR
+BOOT_JDK_BITS
JAVAC_FLAGS
BOOT_JDK_SOURCETARGET
JARSIGNER
@@ -968,6 +969,7 @@
TAIL
SORT
SH
+RMDIR
RM
PRINTF
NAWK
@@ -1146,6 +1148,7 @@
NAWK
PRINTF
RM
+RMDIR
SH
SORT
TAIL
@@ -2025,6 +2028,7 @@
NAWK Override default value for NAWK
PRINTF Override default value for PRINTF
RM Override default value for RM
+ RMDIR Override default value for RMDIR
SH Override default value for SH
SORT Override default value for SORT
TAIL Override default value for TAIL
@@ -4587,7 +4591,7 @@
#CUSTOM_AUTOCONF_INCLUDE
# Do not change or remove the following line, it is needed for consistency checks:
-DATE_WHEN_GENERATED=1444643341
+DATE_WHEN_GENERATED=1445524829
###############################################################################
#
@@ -9514,6 +9518,209 @@
# Publish this variable in the help.
+ if [ -z "${RMDIR+x}" ]; then
+ # The variable is not set by user, try to locate tool using the code snippet
+ for ac_prog in rmdir
+do
+ # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_RMDIR+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ case $RMDIR in
+ [\\/]* | ?:[\\/]*)
+ ac_cv_path_RMDIR="$RMDIR" # Let the user override the test with a path.
+ ;;
+ *)
+ as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+ for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ ac_cv_path_RMDIR="$as_dir/$ac_word$ac_exec_ext"
+ $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+ break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+ ;;
+esac
+fi
+RMDIR=$ac_cv_path_RMDIR
+if test -n "$RMDIR"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $RMDIR" >&5
+$as_echo "$RMDIR" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+ test -n "$RMDIR" && break
+done
+
+ else
+ # The variable is set, but is it from the command line or the environment?
+
+ # Try to remove the string !RMDIR! from our list.
+ try_remove_var=${CONFIGURE_OVERRIDDEN_VARIABLES//!RMDIR!/}
+ if test "x$try_remove_var" = "x$CONFIGURE_OVERRIDDEN_VARIABLES"; then
+ # If it failed, the variable was not from the command line. Ignore it,
+ # but warn the user (except for BASH, which is always set by the calling BASH).
+ if test "xRMDIR" != xBASH; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Ignoring value of RMDIR from the environment. Use command line variables instead." >&5
+$as_echo "$as_me: WARNING: Ignoring value of RMDIR from the environment. Use command line variables instead." >&2;}
+ fi
+ # Try to locate tool using the code snippet
+ for ac_prog in rmdir
+do
+ # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_RMDIR+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ case $RMDIR in
+ [\\/]* | ?:[\\/]*)
+ ac_cv_path_RMDIR="$RMDIR" # Let the user override the test with a path.
+ ;;
+ *)
+ as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+ for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ ac_cv_path_RMDIR="$as_dir/$ac_word$ac_exec_ext"
+ $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+ break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+ ;;
+esac
+fi
+RMDIR=$ac_cv_path_RMDIR
+if test -n "$RMDIR"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $RMDIR" >&5
+$as_echo "$RMDIR" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+ test -n "$RMDIR" && break
+done
+
+ else
+ # If it succeeded, then it was overridden by the user. We will use it
+ # for the tool.
+
+ # First remove it from the list of overridden variables, so we can test
+ # for unknown variables in the end.
+ CONFIGURE_OVERRIDDEN_VARIABLES="$try_remove_var"
+
+ # Check if we try to supply an empty value
+ if test "x$RMDIR" = x; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: Setting user supplied tool RMDIR= (no value)" >&5
+$as_echo "$as_me: Setting user supplied tool RMDIR= (no value)" >&6;}
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for RMDIR" >&5
+$as_echo_n "checking for RMDIR... " >&6; }
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: disabled" >&5
+$as_echo "disabled" >&6; }
+ else
+ # Check if the provided tool contains a complete path.
+ tool_specified="$RMDIR"
+ tool_basename="${tool_specified##*/}"
+ if test "x$tool_basename" = "x$tool_specified"; then
+ # A command without a complete path is provided, search $PATH.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: Will search for user supplied tool RMDIR=$tool_basename" >&5
+$as_echo "$as_me: Will search for user supplied tool RMDIR=$tool_basename" >&6;}
+ # Extract the first word of "$tool_basename", so it can be a program name with args.
+set dummy $tool_basename; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_path_RMDIR+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ case $RMDIR in
+ [\\/]* | ?:[\\/]*)
+ ac_cv_path_RMDIR="$RMDIR" # Let the user override the test with a path.
+ ;;
+ *)
+ as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+ for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ ac_cv_path_RMDIR="$as_dir/$ac_word$ac_exec_ext"
+ $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+ break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+ ;;
+esac
+fi
+RMDIR=$ac_cv_path_RMDIR
+if test -n "$RMDIR"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $RMDIR" >&5
+$as_echo "$RMDIR" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+ if test "x$RMDIR" = x; then
+ as_fn_error $? "User supplied tool $tool_basename could not be found" "$LINENO" 5
+ fi
+ else
+ # Otherwise we believe it is a complete path. Use it as it is.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: Will use user supplied tool RMDIR=$tool_specified" >&5
+$as_echo "$as_me: Will use user supplied tool RMDIR=$tool_specified" >&6;}
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for RMDIR" >&5
+$as_echo_n "checking for RMDIR... " >&6; }
+ if test ! -x "$tool_specified"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: not found" >&5
+$as_echo "not found" >&6; }
+ as_fn_error $? "User supplied tool RMDIR=$tool_specified does not exist or is not executable" "$LINENO" 5
+ fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $tool_specified" >&5
+$as_echo "$tool_specified" >&6; }
+ fi
+ fi
+ fi
+ fi
+
+
+
+ if test "x$RMDIR" = x; then
+ as_fn_error $? "Could not find required tool for RMDIR" "$LINENO" 5
+ fi
+
+
+
+
+
+ # Publish this variable in the help.
+
+
if [ -z "${SH+x}" ]; then
# The variable is not set by user, try to locate tool using the code snippet
for ac_prog in sh
@@ -26920,6 +27127,18 @@
+ # Check if the boot jdk is 32 or 64 bit
+ if "$JAVA" -d64 -version > /dev/null 2>&1; then
+ BOOT_JDK_BITS="64"
+ else
+ BOOT_JDK_BITS="32"
+ fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking if Boot JDK is 32 or 64 bits" >&5
+$as_echo_n "checking if Boot JDK is 32 or 64 bits... " >&6; }
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $BOOT_JDK_BITS" >&5
+$as_echo "$BOOT_JDK_BITS" >&6; }
+
+
###############################################################################
#
@@ -53099,7 +53318,7 @@
# Maximum amount of heap memory.
# Maximum stack size.
JVM_MAX_HEAP=`expr $MEMORY_SIZE / 2`
- if test "x$BUILD_NUM_BITS" = x32; then
+ if test "x$BOOT_JDK_BITS" = "x32"; then
if test "$JVM_MAX_HEAP" -gt "1100"; then
JVM_MAX_HEAP=1100
elif test "$JVM_MAX_HEAP" -lt "512"; then
@@ -53107,10 +53326,7 @@
fi
STACK_SIZE=768
else
- # Running Javac on a JVM on a 64-bit machine, takes more space since 64-bit
- # pointers are used. Apparently, we need to increase the heap and stack
- # space for the jvm. More specifically, when running javac to build huge
- # jdk batch
+ # Running a 64 bit JVM allows for and requires a bigger heap
if test "$JVM_MAX_HEAP" -gt "1600"; then
JVM_MAX_HEAP=1600
elif test "$JVM_MAX_HEAP" -lt "512"; then
--- a/common/autoconf/spec.gmk.in Thu Oct 22 08:47:39 2015 -0700
+++ b/common/autoconf/spec.gmk.in Thu Oct 22 11:12:30 2015 -0700
@@ -504,6 +504,7 @@
PRINTF:=@PRINTF@
PWD:=@THEPWDCMD@
RM:=@RM@
+RMDIR:=@RMDIR@
SED:=@SED@
SH:=@SH@
SORT:=@SORT@
--- a/common/bin/compare.sh Thu Oct 22 08:47:39 2015 -0700
+++ b/common/bin/compare.sh Thu Oct 22 11:12:30 2015 -0700
@@ -51,8 +51,6 @@
STAT_PRINT_SIZE="-c %s"
fi
-UNARCHIVE="$UNZIP -q"
-
COMPARE_EXCEPTIONS_INCLUDE="$SRC_ROOT/common/bin/compare_exceptions.sh.incl"
if [ ! -e "$COMPARE_EXCEPTIONS_INCLUDE" ]; then
echo "Error: Cannot locate the exceptions file, it should have been here: $COMPARE_EXCEPTIONS_INCLUDE"
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/common/bin/update-build-readme.sh Thu Oct 22 11:12:30 2015 -0700
@@ -0,0 +1,62 @@
+#!/bin/bash
+
+# Get an absolute path to this script, since that determines the top-level
+# directory.
+this_script_dir=`dirname $0`
+TOPDIR=`cd $this_script_dir/../.. > /dev/null && pwd`
+
+GREP=grep
+MD_FILE=$TOPDIR/README-builds.md
+HTML_FILE=$TOPDIR/README-builds.html
+
+# Locate the markdown processor tool and check that it is the correct version.
+locate_markdown_processor() {
+ if [ -z "$MARKDOWN" ]; then
+ MARKDOWN=`which markdown 2> /dev/null`
+ if [ -z "$MARKDOWN" ]; then
+ echo "Error: Cannot locate markdown processor" 1>&2
+ exit 1
+ fi
+ fi
+
+ # Test version
+ MARKDOWN_VERSION=`$MARKDOWN -version | $GREP version`
+ if [ "x$MARKDOWN_VERSION" != "xThis is Markdown, version 1.0.1." ]; then
+ echo "Error: Expected markdown version 1.0.1." 1>&2
+ echo "Actual version found: $MARKDOWN_VERSION" 1>&2
+ echo "Download markdown here: https://daringfireball.net/projects/markdown/" 1>&2
+ exit 1
+ fi
+
+}
+
+# Verify that the source markdown file looks sound.
+verify_source_code() {
+ TOO_LONG_LINES=`$GREP -E -e '^.{80}.+$' $MD_FILE`
+ if [ "x$TOO_LONG_LINES" != x ]; then
+ echo "Warning: The following lines are longer than 80 characters:"
+ $GREP -E -e '^.{80}.+$' $MD_FILE
+ fi
+}
+
+# Convert the markdown file to html format.
+process_source() {
+ echo "Generating html file from markdown"
+ cat > $HTML_FILE << END
+<html>
+ <head>
+ <title>OpenJDK Build README</title>
+ </head>
+ <body>
+END
+ markdown $MD_FILE >> $HTML_FILE
+ cat >> $HTML_FILE <<END
+ </body>
+</html>
+END
+ echo "Done"
+}
+
+locate_markdown_processor
+verify_source_code
+process_source
--- a/make/CompileJavaModules.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/CompileJavaModules.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -438,6 +438,18 @@
################################################################################
+jdk.vm.ci_EXCLUDE_FILES += \
+ jdk/vm/ci/options/processor/OptionProcessor.java \
+ jdk/vm/ci/service/processor/ServiceProviderProcessor.java \
+ #
+
+jdk.vm.ci_EXCLUDES += \
+ META-INF/jvmci.options \
+ META-INF/jvmci.providers \
+ #
+
+################################################################################
+
jdk.xml.bind_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS
jdk.xml.bind_CLEAN := .properties
jdk.xml.bind_COPY := .xsd JAXBContextFactory.java ZeroOneBooleanAdapter.java
@@ -479,6 +491,7 @@
endif
SHARE_SRC_DIRS += \
+ $(HOTSPOT_TOPDIR)/src/$1/share/classes \
$(JDK_TOPDIR)/src/$1/share/classes \
$(LANGTOOLS_TOPDIR)/src/$1/share/classes \
$(CORBA_TOPDIR)/src/$1/share/classes \
@@ -531,7 +544,7 @@
$$(eval $$(call SetupJavaCompilation,$1, \
SETUP := $$(if $$($1_SETUP), $$($1_SETUP), GENERATE_JDKBYTECODE), \
- SRC := $$(wildcard $$(call ALL_SRC_DIRS,$1)), \
+ SRC := $$(if $$($1_SRC), $$($1_SRC), $$(wildcard $$(call ALL_SRC_DIRS,$1))), \
INCLUDES := $(JDK_USER_DEFINED_FILTER),\
BIN := $$(if $$($1_BIN), $$($1_BIN), $(JDK_OUTPUTDIR)/modules/$1), \
HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$1, \
--- a/make/Images.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/Images.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -39,7 +39,8 @@
MAIN_MODULES += java.se java.smartcardio jdk.httpserver jdk.sctp \
jdk.security.auth jdk.security.jgss jdk.pack200 jdk.xml.dom \
- jdk.accessibility jdk.internal.le jdk.scripting.nashorn.shell
+ jdk.accessibility jdk.internal.le jdk.scripting.nashorn.shell \
+ jdk.vm.ci
# providers
PROVIDER_MODULES += jdk.charsets jdk.crypto.ec jdk.crypto.pkcs11 jdk.jvmstat jdk.localedata \
@@ -48,7 +49,8 @@
# tools
TOOLS_MODULES += jdk.attach jdk.compiler jdk.dev \
jdk.javadoc jdk.jcmd jdk.jconsole jdk.hotspot.agent jdk.jartool \
- jdk.jdeps jdk.jdi jdk.jdwp.agent jdk.policytool jdk.rmic jdk.xml.bind jdk.xml.ws
+ jdk.jdeps jdk.jdi jdk.jdwp.agent jdk.jshell jdk.policytool jdk.rmic \
+ jdk.xml.bind jdk.xml.ws
ifeq ($(OPENJDK_TARGET_OS), windows)
PROVIDER_MODULES += jdk.crypto.mscapi
--- a/make/Init.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/Init.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -137,7 +137,9 @@
# The spec files depend on the autoconf source code. This check makes sure
# the configuration is up to date after changes to configure.
- $(SPECS): $(wildcard $(topdir)/common/autoconf/*)
+ CUSTOM_CONFIG_DIR ?= $(topdir)/closed/autoconf
+
+ $(SPECS): $(wildcard $(topdir)/common/autoconf/*) $(wildcard $(CUSTOM_CONFIG_DIR)/*)
ifeq ($(CONF_CHECK), fail)
@echo "Error: The configuration is not up to date for '$(lastword $(subst /, , $(dir $@)))'."
$(call PrintConfCheckFailed)
--- a/make/Main.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/Main.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -107,6 +107,7 @@
JDK_GENSRC_TARGETS := $(filter %-gensrc-jdk, $(GENSRC_TARGETS))
LANGTOOLS_GENSRC_TARGETS := $(filter %-gensrc-langtools, $(GENSRC_TARGETS))
CORBA_GENSRC_TARGETS := $(filter %-gensrc-corba, $(GENSRC_TARGETS))
+HOTSPOT_GENSRC_TARGETS := $(filter %-gensrc-hotspot, $(GENSRC_TARGETS))
ALL_TARGETS += $(GENSRC_TARGETS)
@@ -128,7 +129,8 @@
FILE_PREFIX := Copy, \
MAKE_SUBDIR := copy, \
CHECK_MODULES := $(ALL_MODULES), \
- USE_WRAPPER := true))
+ USE_WRAPPER := true, \
+ MULTIPLE_MAKEFILES := true))
ALL_TARGETS += $(COPY_TARGETS)
@@ -352,6 +354,8 @@
$(CORBA_GENSRC_TARGETS): interim-langtools
+ $(HOTSPOT_GENSRC_TARGETS): interim-langtools
+
$(JDK_GENSRC_TARGETS): interim-langtools buildtools-jdk
$(GENDATA_TARGETS): interim-langtools buildtools-jdk
@@ -415,6 +419,9 @@
# Explicitly add dependencies for special targets
java.base-java: unpack-sec
+ # The copy target copies files generated by gensrc
+ java.base-copy-hotspot: java.base-gensrc-hotspot
+
jdk.jdeps-gendata: java rmic
zip-security: java.base-java java.security.jgss-java java.security.jgss-libs \
--- a/make/MainSupport.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/MainSupport.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -50,6 +50,8 @@
@$(PRINTF) "Cleaning test $(strip $1) ..."
@$(PRINTF) "\n" $(LOG_DEBUG)
$(RM) -r $(SUPPORT_OUTPUTDIR)/test/$(strip $(subst -,/,$1))
+ # Remove as much of the test directory structure as is empty
+ $(RMDIR) -p $(dir $(SUPPORT_OUTPUTDIR)/test/$(strip $(subst -,/,$1))) 2> /dev/null || true
@$(PRINTF) " done\n"
endef
@@ -108,7 +110,8 @@
################################################################################
-MAKE_TOPDIR_LIST := $(JDK_TOPDIR) $(CORBA_TOPDIR) $(LANGTOOLS_TOPDIR)
+MAKE_TOPDIR_LIST := $(JDK_TOPDIR) $(CORBA_TOPDIR) $(LANGTOOLS_TOPDIR) \
+ $(HOTSPOT_TOPDIR)
MAKE_MAKEDIR_LIST := make
# Helper macro for DeclareRecipesForPhase
@@ -179,7 +182,7 @@
# FILE_PREFIX : File prefix for this build phase
# USE_WRAPPER : Set to true to use ModuleWrapper.gmk
# CHECK_MODULES : List of modules to try
-# MULTIPLE_MAKEFILES : Set to true to handle makefils for the same module in
+# MULTIPLE_MAKEFILES : Set to true to handle makefiles for the same module and
# phase in multiple repos
# Exported variables:
# $1_MODULES : All modules that had rules generated
--- a/make/common/Modules.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/common/Modules.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -33,6 +33,7 @@
# Module list macros
ALL_TOP_SRC_DIRS := \
+ $(HOTSPOT_TOPDIR)/src \
$(JDK_TOPDIR)/src \
$(LANGTOOLS_TOPDIR)/src \
$(CORBA_TOPDIR)/src \
--- a/make/devkit/Tools.gmk Thu Oct 22 08:47:39 2015 -0700
+++ b/make/devkit/Tools.gmk Thu Oct 22 11:12:30 2015 -0700
@@ -49,9 +49,9 @@
# Define external dependencies
# Latest that could be made to work.
-gcc_ver := gcc-4.8.2
-binutils_ver := binutils-2.24
-ccache_ver := ccache-3.1.9
+gcc_ver := gcc-4.9.2
+binutils_ver := binutils-2.25
+ccache_ver := ccache-3.2.1
mpfr_ver := mpfr-3.0.1
gmp_ver := gmp-4.3.2
mpc_ver := mpc-1.0.1
--- a/make/devkit/createWindowsDevkit.sh Thu Oct 22 08:47:39 2015 -0700
+++ b/make/devkit/createWindowsDevkit.sh Thu Oct 22 11:12:30 2015 -0700
@@ -32,10 +32,11 @@
VS_VERSION_NUM="12.0"
VS_VERSION_NUM_NODOT="120"
SDK_VERSION="8.1"
+VS_VERSION_SP="SP4"
SCRIPT_DIR="$(cd "$(dirname $0)" > /dev/null && pwd)"
BUILD_DIR="${SCRIPT_DIR}/../../build/devkit"
-DEVKIT_ROOT="${BUILD_DIR}/VS${VS_VERSION}-devkit"
+DEVKIT_ROOT="${BUILD_DIR}/VS${VS_VERSION}${VS_VERSION_SP}-devkit"
DEVKIT_BUNDLE="${DEVKIT_ROOT}.tar.gz"
echo "Creating devkit in $DEVKIT_ROOT"
@@ -103,7 +104,7 @@
echo "Generating devkit.info..."
rm -f $DEVKIT_ROOT/devkit.info
echo-info "# This file describes to configure how to interpret the contents of this devkit"
-echo-info "DEVKIT_NAME=\"Microsoft Visual Studio $VS_VERSION (devkit)\""
+echo-info "DEVKIT_NAME=\"Microsoft Visual Studio $VS_VERSION $VS_VERSION_SP (devkit)\""
echo-info "DEVKIT_VS_VERSION=\"$VS_VERSION\""
echo-info ""
echo-info "DEVKIT_TOOLCHAIN_PATH_x86=\"\$DEVKIT_ROOT/VC/bin:\$DEVKIT_ROOT/$SDK_VERSION/bin/x86\""
--- a/make/jprt.properties Thu Oct 22 08:47:39 2015 -0700
+++ b/make/jprt.properties Thu Oct 22 11:12:30 2015 -0700
@@ -122,11 +122,18 @@
jprt.i586.productOpen.build.configure.args= \
${my.i586.default.build.configure.args} \
${jprt.productOpen.build.configure.args}
+jprt.linux_i586.build.configure.args= \
+ --with-devkit=$GCC492_OEL64_HOME \
+ ${jprt.i586.build.configure.args}
+jprt.linux_x64.build.configure.args= \
+ --with-devkit=$GCC492_OEL64_HOME
jprt.windows_i586.build.configure.args= \
- --with-devkit=$VS2013_HOME \
+ --with-devkit=$VS2013SP4_HOME \
${jprt.i586.build.configure.args}
jprt.windows_x64.build.configure.args= \
- --with-devkit=$VS2013_HOME
+ --with-devkit=$VS2013SP4_HOME
+jprt.macosx_x64.build.configure.args= \
+ --with-devkit=$XCODE_511_HOME
########
#
--- a/modules.xml Thu Oct 22 08:47:39 2015 -0700
+++ b/modules.xml Thu Oct 22 11:12:30 2015 -0700
@@ -237,6 +237,7 @@
<to>java.instrument</to>
<to>jdk.jfr</to>
<to>jdk.scripting.nashorn</to>
+ <to>jdk.vm.ci</to>
</export>
<export>
<name>jdk.internal.org.objectweb.asm.commons</name>
@@ -290,6 +291,7 @@
<to>jdk.security.auth</to>
<to>jdk.security.jgss</to>
<to>jdk.snmp</to>
+ <to>jdk.vm.ci</to>
<to>java.instrument</to>
</export>
<export>
@@ -788,6 +790,19 @@
</export>
</module>
<module>
+ <name>jdk.jshell</name>
+ <depend>java.base</depend>
+ <depend re-exports="true">java.compiler</depend>
+ <depend>jdk.compiler</depend>
+ <depend>java.desktop</depend>
+ <depend>java.prefs</depend>
+ <depend>jdk.jdi</depend>
+ <depend>jdk.internal.le</depend>
+ <export>
+ <name>jdk.jshell</name>
+ </export>
+ </module>
+ <module>
<name>java.instrument</name>
<depend>java.base</depend>
<export>
@@ -1547,14 +1562,17 @@
</export>
<export>
<name>com.sun.tools.javac.api</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
</export>
<export>
<name>com.sun.tools.javac.code</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
</export>
<export>
<name>com.sun.tools.javac.comp</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
</export>
<export>
@@ -1564,10 +1582,12 @@
</export>
<export>
<name>com.sun.tools.javac.jvm</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
</export>
<export>
<name>com.sun.tools.javac.main</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
</export>
<export>
@@ -1575,6 +1595,10 @@
<to>jdk.javadoc</to>
</export>
<export>
+ <name>com.sun.tools.javac.parser</name>
+ <to>jdk.jshell</to>
+ </export>
+ <export>
<name>com.sun.tools.javac.platform</name>
<to>jdk.javadoc</to>
</export>
@@ -1584,10 +1608,12 @@
</export>
<export>
<name>com.sun.tools.javac.tree</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
</export>
<export>
<name>com.sun.tools.javac.util</name>
+ <to>jdk.jshell</to>
<to>jdk.javadoc</to>
<to>jdk.jdeps</to>
</export>
@@ -1648,22 +1674,27 @@
<depend>java.base</depend>
<export>
<name>jdk.internal.jline</name>
+ <to>jdk.jshell</to>
<to>jdk.scripting.nashorn.shell</to>
</export>
<export>
<name>jdk.internal.jline.console</name>
+ <to>jdk.jshell</to>
<to>jdk.scripting.nashorn.shell</to>
</export>
<export>
<name>jdk.internal.jline.console.completer</name>
+ <to>jdk.jshell</to>
<to>jdk.scripting.nashorn.shell</to>
</export>
<export>
<name>jdk.internal.jline.console.history</name>
+ <to>jdk.jshell</to>
<to>jdk.scripting.nashorn.shell</to>
</export>
<export>
<name>jdk.internal.jline.internal</name>
+ <to>jdk.jshell</to>
<to>jdk.scripting.nashorn.shell</to>
</export>
</module>
@@ -1872,6 +1903,18 @@
</export>
</module>
<module>
+ <name>jdk.vm.ci</name>
+ <depend>java.base</depend>
+ <export>
+ <name>jdk.vm.ci.hotspot</name>
+ <to>jdk.jfr</to>
+ </export>
+ <export>
+ <name>jdk.vm.ci.hotspot.events</name>
+ <to>jdk.jfr</to>
+ </export>
+ </module>
+ <module>
<name>jdk.xml.bind</name>
<depend>java.activation</depend>
<depend>java.base</depend>
--- a/test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java Thu Oct 22 08:47:39 2015 -0700
+++ b/test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java Thu Oct 22 11:12:30 2015 -0700
@@ -67,6 +67,7 @@
public class LingeredApp {
private static final long spinDelay = 1000;
+ private static final int appWaitTime = 100;
private final String lockFileName;
private long lockCreationTime;
@@ -111,6 +112,12 @@
this.storedAppOutput = new ArrayList<String>();
}
+ public LingeredApp() {
+ final String lockName = UUID.randomUUID().toString() + ".lck";
+ this.lockFileName = lockName;
+ this.storedAppOutput = new ArrayList<String>();
+ }
+
/**
*
* @return name of lock file
@@ -338,21 +345,18 @@
* High level interface for test writers
*/
/**
- * Factory method that creates SmartAppTest object with ready to use application
- * lock name is autogenerated, wait timeout is hardcoded
+ * Factory method that creates LingeredApp object with ready to use application
+ * lock name is autogenerated
* @param cmd - vm options, could be null to auto add testvm.options
* @return LingeredApp object
* @throws IOException
*/
public static LingeredApp startApp(List<String> cmd) throws IOException {
- final String lockName = UUID.randomUUID().toString() + ".lck";
- final int waitTime = 10;
-
- LingeredApp a = new LingeredApp(lockName);
+ LingeredApp a = new LingeredApp();
a.createLock();
try {
a.runApp(cmd);
- a.waitAppReady(waitTime);
+ a.waitAppReady(appWaitTime);
} catch (Exception ex) {
a.deleteLock();
throw ex;
@@ -361,6 +365,26 @@
return a;
}
+ /**
+ * Factory method that starts pre-created LingeredApp
+ * lock name is autogenerated
+ * @param cmd - vm options, could be null to auto add testvm.options
+ * @param theApp - app to start
+ * @return LingeredApp object
+ * @throws IOException
+ */
+
+ public static void startApp(List<String> cmd, LingeredApp theApp) throws IOException {
+ theApp.createLock();
+ try {
+ theApp.runApp(cmd);
+ theApp.waitAppReady(appWaitTime);
+ } catch (Exception ex) {
+ theApp.deleteLock();
+ throw ex;
+ }
+ }
+
public static LingeredApp startApp() throws IOException {
return startApp(null);
}
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java Thu Oct 22 11:12:30 2015 -0700
@@ -0,0 +1,81 @@
+/*
+ * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+package jdk.test.lib.apps;
+
+import java.util.concurrent.Phaser;
+
+public class LingeredAppWithDeadlock extends LingeredApp {
+
+ private static final Object Lock1 = new Object();
+ private static final Object Lock2 = new Object();
+
+ private static volatile int reachCount = 0;
+
+ private static final Phaser p = new Phaser(2);
+
+ private static class ThreadOne extends Thread {
+ public void run() {
+ // wait Lock2 is locked
+ p.arriveAndAwaitAdvance();
+ synchronized (Lock1) {
+ // signal Lock1 is locked
+ p.arriveAndAwaitAdvance();
+ synchronized (Lock2) {
+ reachCount += 1;
+ }
+ }
+ }
+ }
+
+ private static class ThreadTwo extends Thread {
+ public void run() {
+ synchronized (Lock2) {
+ // signal Lock2 is locked
+ p.arriveAndAwaitAdvance();
+ // wait Lock1 is locked
+ p.arriveAndAwaitAdvance();
+ synchronized (Lock1) {
+ reachCount += 1;
+ }
+ }
+ }
+ }
+
+ public static void main(String args[]) {
+ if (args.length != 1) {
+ System.err.println("Lock file name is not specified");
+ System.exit(7);
+ }
+
+ // Run two theads that should come to deadlock
+ new ThreadOne().start();
+ new ThreadTwo().start();
+
+ if (reachCount > 0) {
+ // Not able to deadlock, exiting
+ System.exit(3);
+ }
+
+ LingeredApp.main(args);
+ }
+ }
--- a/test/lib/sun/hotspot/WhiteBox.java Thu Oct 22 08:47:39 2015 -0700
+++ b/test/lib/sun/hotspot/WhiteBox.java Thu Oct 22 11:12:30 2015 -0700
@@ -112,6 +112,12 @@
public native void forceSafepoint();
+ private native long getConstantPool0(Class<?> aClass);
+ public long getConstantPool(Class<?> aClass) {
+ Objects.requireNonNull(aClass);
+ return getConstantPool0(aClass);
+ }
+
// JVMTI
private native void addToBootstrapClassLoaderSearch0(String segment);
public void addToBootstrapClassLoaderSearch(String segment){
@@ -159,6 +165,7 @@
public native int NMTGetHashSize();
// Compiler
+ public native int matchesMethod(Executable method, String pattern);
public native int deoptimizeFrames(boolean makeNotEntrant);
public native void deoptimizeAll();
public boolean isMethodCompiled(Executable method) {
@@ -288,6 +295,11 @@
public native void forceNMethodSweep();
public native Object[] getCodeHeapEntries(int type);
public native int getCompilationActivityMode();
+ private native long getMethodData0(Executable method);
+ public long getMethodData(Executable method) {
+ Objects.requireNonNull(method);
+ return getMethodData0(method);
+ }
public native Object[] getCodeBlob(long addr);
// Intered strings
--- a/test/lib/sun/hotspot/code/NMethod.java Thu Oct 22 08:47:39 2015 -0700
+++ b/test/lib/sun/hotspot/code/NMethod.java Thu Oct 22 11:12:30 2015 -0700
@@ -35,14 +35,16 @@
}
private NMethod(Object[] obj) {
super((Object[])obj[0]);
- assert obj.length == 4;
+ assert obj.length == 5;
comp_level = (Integer) obj[1];
insts = (byte[]) obj[2];
compile_id = (Integer) obj[3];
+ address = (Long) obj[4];
}
public final byte[] insts;
public final int comp_level;
public final int compile_id;
+ public final long address;
@Override
public String toString() {
@@ -51,6 +53,7 @@
+ ", insts=" + insts
+ ", comp_level=" + comp_level
+ ", compile_id=" + compile_id
+ + ", address=" + address
+ '}';
}
}