< prev index next >

doc/building.html

Print this page

        

*** 1,26 **** <!DOCTYPE html> ! <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang=""> <head> ! <meta charset="utf-8" /> ! <meta name="generator" content="pandoc" /> ! <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" /> <title>Building the JDK</title> ! <style type="text/css"> ! code{white-space: pre-wrap;} ! span.smallcaps{font-variant: small-caps;} ! span.underline{text-decoration: underline;} ! div.column{display: inline-block; vertical-align: top; width: 50%;} ! </style> ! <link rel="stylesheet" href="../make/data/docs-resources/resources/jdk-default.css" /> <!--[if lt IE 9]> <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script> <![endif]--> <style type="text/css">pre, code, tt { color: #1d6ae5; }</style> </head> <body> ! <header id="title-block-header"> <h1 class="title">Building the JDK</h1> </header> <nav id="TOC"> <ul> <li><a href="#tldr-instructions-for-the-impatient">TL;DR (Instructions for the Impatient)</a></li> --- 1,21 ---- <!DOCTYPE html> ! <html> <head> ! <meta charset="utf-8"> ! <meta name="generator" content="pandoc"> ! <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes"> <title>Building the JDK</title> ! <style type="text/css">code{white-space: pre;}</style> ! <link rel="stylesheet" href="../make/data/docs-resources/resources/jdk-default.css"> <!--[if lt IE 9]> <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script> <![endif]--> <style type="text/css">pre, code, tt { color: #1d6ae5; }</style> </head> <body> ! <header> <h1 class="title">Building the JDK</h1> </header> <nav id="TOC"> <ul> <li><a href="#tldr-instructions-for-the-impatient">TL;DR (Instructions for the Impatient)</a></li>
*** 143,153 **** <p>For a smooth building experience, it is recommended that you follow these rules on where and how to check out the source code.</p> <ul> <li><p>Do not check out the source code in a path which contains spaces. Chances are the build will not work. This is most likely to be an issue on Windows systems.</p></li> <li><p>Do not check out the source code in a path which has a very long name or is nested many levels deep. Chances are you will hit an OS limitation during the build.</p></li> <li><p>Put the source code on a local disk, not a network share. If possible, use an SSD. The build process is very disk intensive, and having slow disk access will significantly increase build times. If you need to use a network share for the source code, see below for suggestions on how to keep the build artifacts on a local disk.</p></li> ! <li><p>On Windows, if using <a href="#cygwin">Cygwin</a>, extra care must be taken to make sure the environment is consistent. It is recommended that you follow this procedure:</p> <ul> <li><p>Create the directory that is going to contain the top directory of the JDK clone by using the <code>mkdir</code> command in the Cygwin bash shell. That is, do <em>not</em> create it using Windows Explorer. This will ensure that it will have proper Cygwin attributes, and that it's children will inherit those attributes.</p></li> <li><p>Do not put the JDK clone in a path under your Cygwin home directory. This is especially important if your user name contains spaces and/or mixed upper and lower case letters.</p></li> <li><p>Clone the JDK repository using the Cygwin command line <code>hg</code> client as instructed in this document. That is, do <em>not</em> use another Mercurial client such as TortoiseHg.</p></li> </ul> --- 138,148 ---- <p>For a smooth building experience, it is recommended that you follow these rules on where and how to check out the source code.</p> <ul> <li><p>Do not check out the source code in a path which contains spaces. Chances are the build will not work. This is most likely to be an issue on Windows systems.</p></li> <li><p>Do not check out the source code in a path which has a very long name or is nested many levels deep. Chances are you will hit an OS limitation during the build.</p></li> <li><p>Put the source code on a local disk, not a network share. If possible, use an SSD. The build process is very disk intensive, and having slow disk access will significantly increase build times. If you need to use a network share for the source code, see below for suggestions on how to keep the build artifacts on a local disk.</p></li> ! <li><p>On Windows, extra care must be taken to make sure the <a href="#cygwin">Cygwin</a> environment is consistent. It is recommended that you follow this procedure:</p> <ul> <li><p>Create the directory that is going to contain the top directory of the JDK clone by using the <code>mkdir</code> command in the Cygwin bash shell. That is, do <em>not</em> create it using Windows Explorer. This will ensure that it will have proper Cygwin attributes, and that it's children will inherit those attributes.</p></li> <li><p>Do not put the JDK clone in a path under your Cygwin home directory. This is especially important if your user name contains spaces and/or mixed upper and lower case letters.</p></li> <li><p>Clone the JDK repository using the Cygwin command line <code>hg</code> client as instructed in this document. That is, do <em>not</em> use another Mercurial client such as TortoiseHg.</p></li> </ul>
*** 178,229 **** </tr> </thead> <tbody> <tr class="odd"> <td style="text-align: left;">Linux</td> ! <td style="text-align: left;">Oracle Enterprise Linux 6.4 / 7.6</td> </tr> <tr class="even"> <td style="text-align: left;">Solaris</td> ! <td style="text-align: left;">Solaris 11.3 SRU 20</td> </tr> <tr class="odd"> <td style="text-align: left;">macOS</td> ! <td style="text-align: left;">Mac OS X 10.13 (High Sierra)</td> </tr> <tr class="even"> <td style="text-align: left;">Windows</td> <td style="text-align: left;">Windows Server 2012 R2</td> </tr> </tbody> </table> ! <p>The double version numbers for Linux and Solaris are due to the hybrid model used at Oracle, where header files and external libraries from an older version are used when building on a more modern version of the OS.</p> <p>The Build Group has a wiki page with <a href="https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms">Supported Build Platforms</a>. From time to time, this is updated by contributors to list successes or failures of building on different platforms.</p> <h3 id="windows">Windows</h3> <p>Windows XP is not a supported platform, but all newer Windows should be able to build the JDK.</p> <p>On Windows, it is important that you pay attention to the instructions in the <a href="#special-considerations">Special Considerations</a>.</p> ! <p>Windows is the only non-POSIX OS supported by the JDK, and as such, requires some extra care. A POSIX support layer is required to build on Windows. Currently, the only supported such layers are Cygwin and Windows Subsystem for Linux (WSL). (Msys is no longer supported due to a too old bash; msys2 would likely be possible to support in a future version but that would require effort to implement.)</p> <p>Internally in the build system, all paths are represented as Unix-style paths, e.g. <code>/cygdrive/c/hg/jdk9/Makefile</code> rather than <code>C:\hg\jdk9\Makefile</code>. This rule also applies to input to the build system, e.g. in arguments to <code>configure</code>. So, use <code>--with-msvcr-dll=/cygdrive/c/msvcr100.dll</code> rather than <code>--with-msvcr-dll=c:\msvcr100.dll</code>. For details on this conversion, see the section on <a href="#fixpath">Fixpath</a>.</p> <h4 id="cygwin">Cygwin</h4> ! <p>A functioning <a href="http://www.cygwin.com/">Cygwin</a> environment is required for building the JDK on Windows. If you have a 64-bit OS, we strongly recommend using the 64-bit version of Cygwin.</p> <p><strong>Note:</strong> Cygwin has a model of continuously updating all packages without any easy way to install or revert to a specific version of a package. This means that whenever you add or update a package in Cygwin, you might (inadvertently) update tools that are used by the JDK build process, and that can cause unexpected build problems.</p> ! <p>The JDK requires GNU Make 4.0 or greater in Cygwin. This is usually not a problem, since Cygwin currently only distributes GNU Make at a version above 4.0.</p> <p>Apart from the basic Cygwin installation, the following packages must also be installed:</p> <ul> <li><code>autoconf</code></li> <li><code>make</code></li> <li><code>zip</code></li> <li><code>unzip</code></li> </ul> <p>Often, you can install these packages using the following command line:</p> <pre><code>&lt;path to Cygwin setup&gt;/setup-x86_64 -q -P autoconf -P make -P unzip -P zip</code></pre> <p>Unfortunately, Cygwin can be unreliable in certain circumstances. If you experience build tool crashes or strange issues when building on Windows, please check the Cygwin FAQ on the <a href="https://cygwin.com/faq/faq.html#faq.using.bloda">&quot;BLODA&quot; list</a> and the section on <a href="https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures">fork() failures</a>.</p> - <h4 id="windows-subsystem-for-linux-wsl">Windows Subsystem for Linux (WSL)</h4> - <p>Windows 10 1809 or newer is supported due to a dependency on the wslpath utility and support for environment variable sharing through WSLENV. Version 1803 can work but intermittent build failures have been observed.</p> - <p>It's possible to build both Windows and Linux binaries from WSL. To build Windows binaries, you must use a Windows boot JDK (located in a Windows-accessible directory). To build Linux binaries, you must use a Linux boot JDK. The default behavior is to build for Windows. To build for Linux, pass <code>--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu</code> to <code>configure</code>.</p> - <p>If building Windows binaries, the source code must be located in a Windows- accessible directory. This is because Windows executables (such as Visual Studio and the boot JDK) must be able to access the source code. Also, the drive where the source is stored must be mounted as case-insensitive by changing either /etc/fstab or /etc/wsl.conf in WSL. Individual directories may be corrected using the fsutil tool in case the source was cloned before changing the mount options.</p> - <p>Note that while it's possible to build on WSL, testing is still not fully supported.</p> <h3 id="solaris">Solaris</h3> <p>See <code>make/devkit/solaris11.1-package-list.txt</code> for a list of recommended packages to install when building on Solaris. The versions specified in this list is the versions used by the daily builds at Oracle, and is likely to work properly.</p> <p>Older versions of Solaris shipped a broken version of <code>objcopy</code>. At least version 2.21.1 is needed, which is provided by Solaris 11 Update 1. Objcopy is needed if you want to have external debug symbols. Please make sure you are using at least version 2.21.1 of objcopy, or that you disable external debug symbols.</p> <h3 id="macos">macOS</h3> <p>Apple is using a quite aggressive scheme of pushing OS updates, and coupling these updates with required updates of Xcode. Unfortunately, this makes it difficult for a project such as the JDK to keep pace with a continuously updated machine running macOS. See the section on <a href="#apple-xcode">Apple Xcode</a> on some strategies to deal with this.</p> --- 173,219 ---- </tr> </thead> <tbody> <tr class="odd"> <td style="text-align: left;">Linux</td> ! <td style="text-align: left;">Oracle Enterprise Linux 6.4 / 7.1 (using kernel 3.8.13)</td> </tr> <tr class="even"> <td style="text-align: left;">Solaris</td> ! <td style="text-align: left;">Solaris 11.1 SRU 21.4.1 / 11.2 SRU 5.5</td> </tr> <tr class="odd"> <td style="text-align: left;">macOS</td> ! <td style="text-align: left;">Mac OS X 10.9 (Mavericks) / 10.10 (Yosemite)</td> </tr> <tr class="even"> <td style="text-align: left;">Windows</td> <td style="text-align: left;">Windows Server 2012 R2</td> </tr> </tbody> </table> ! <p>The double version numbers for Linux, Solaris and macOS is due to the hybrid model used at Oracle, where header files and external libraries from an older version are used when building on a more modern version of the OS.</p> <p>The Build Group has a wiki page with <a href="https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms">Supported Build Platforms</a>. From time to time, this is updated by contributors to list successes or failures of building on different platforms.</p> <h3 id="windows">Windows</h3> <p>Windows XP is not a supported platform, but all newer Windows should be able to build the JDK.</p> <p>On Windows, it is important that you pay attention to the instructions in the <a href="#special-considerations">Special Considerations</a>.</p> ! <p>Windows is the only non-POSIX OS supported by the JDK, and as such, requires some extra care. A POSIX support layer is required to build on Windows. Currently, the only supported such layer is Cygwin. (Msys is no longer supported due to a too old bash; msys2 and the new Windows Subsystem for Linux (WSL) would likely be possible to support in a future version but that would require effort to implement.)</p> <p>Internally in the build system, all paths are represented as Unix-style paths, e.g. <code>/cygdrive/c/hg/jdk9/Makefile</code> rather than <code>C:\hg\jdk9\Makefile</code>. This rule also applies to input to the build system, e.g. in arguments to <code>configure</code>. So, use <code>--with-msvcr-dll=/cygdrive/c/msvcr100.dll</code> rather than <code>--with-msvcr-dll=c:\msvcr100.dll</code>. For details on this conversion, see the section on <a href="#fixpath">Fixpath</a>.</p> <h4 id="cygwin">Cygwin</h4> ! <p>A functioning <a href="http://www.cygwin.com/">Cygwin</a> environment is thus required for building the JDK on Windows. If you have a 64-bit OS, we strongly recommend using the 64-bit version of Cygwin.</p> <p><strong>Note:</strong> Cygwin has a model of continuously updating all packages without any easy way to install or revert to a specific version of a package. This means that whenever you add or update a package in Cygwin, you might (inadvertently) update tools that are used by the JDK build process, and that can cause unexpected build problems.</p> ! <p>The JDK requires GNU Make 4.0 or greater on Windows. This is usually not a problem, since Cygwin currently only distributes GNU Make at a version above 4.0.</p> <p>Apart from the basic Cygwin installation, the following packages must also be installed:</p> <ul> <li><code>autoconf</code></li> <li><code>make</code></li> <li><code>zip</code></li> <li><code>unzip</code></li> </ul> <p>Often, you can install these packages using the following command line:</p> <pre><code>&lt;path to Cygwin setup&gt;/setup-x86_64 -q -P autoconf -P make -P unzip -P zip</code></pre> <p>Unfortunately, Cygwin can be unreliable in certain circumstances. If you experience build tool crashes or strange issues when building on Windows, please check the Cygwin FAQ on the <a href="https://cygwin.com/faq/faq.html#faq.using.bloda">&quot;BLODA&quot; list</a> and the section on <a href="https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures">fork() failures</a>.</p> <h3 id="solaris">Solaris</h3> <p>See <code>make/devkit/solaris11.1-package-list.txt</code> for a list of recommended packages to install when building on Solaris. The versions specified in this list is the versions used by the daily builds at Oracle, and is likely to work properly.</p> <p>Older versions of Solaris shipped a broken version of <code>objcopy</code>. At least version 2.21.1 is needed, which is provided by Solaris 11 Update 1. Objcopy is needed if you want to have external debug symbols. Please make sure you are using at least version 2.21.1 of objcopy, or that you disable external debug symbols.</p> <h3 id="macos">macOS</h3> <p>Apple is using a quite aggressive scheme of pushing OS updates, and coupling these updates with required updates of Xcode. Unfortunately, this makes it difficult for a project such as the JDK to keep pace with a continuously updated machine running macOS. See the section on <a href="#apple-xcode">Apple Xcode</a> on some strategies to deal with this.</p>
*** 235,245 **** <p>For apt-based distributions (Debian, Ubuntu, etc), try this:</p> <pre><code>sudo apt-get install build-essential</code></pre> <p>For rpm-based distributions (Fedora, Red Hat, etc), try this:</p> <pre><code>sudo yum groupinstall &quot;Development Tools&quot;</code></pre> <h3 id="aix">AIX</h3> ! <p>Please consult the AIX section of the <a href="https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms">Supported Build Platforms</a> OpenJDK Build Wiki page for details about which versions of AIX are supported.</p> <h2 id="native-compiler-toolchain-requirements">Native Compiler (Toolchain) Requirements</h2> <p>Large portions of the JDK consists of native code, that needs to be compiled to be able to run on the target platform. In theory, toolchain and operating system should be independent factors, but in practice there's more or less a one-to-one correlation between target operating system and toolchain.</p> <table> <thead> <tr class="header"> --- 225,235 ---- <p>For apt-based distributions (Debian, Ubuntu, etc), try this:</p> <pre><code>sudo apt-get install build-essential</code></pre> <p>For rpm-based distributions (Fedora, Red Hat, etc), try this:</p> <pre><code>sudo yum groupinstall &quot;Development Tools&quot;</code></pre> <h3 id="aix">AIX</h3> ! <p>The regular builds by SAP is using AIX version 7.1, but AIX 5.3 is also supported. See the <a href="http://cr.openjdk.java.net/~simonis/ppc-aix-port">OpenJDK PowerPC Port Status Page</a> for details.</p> <h2 id="native-compiler-toolchain-requirements">Native Compiler (Toolchain) Requirements</h2> <p>Large portions of the JDK consists of native code, that needs to be compiled to be able to run on the target platform. In theory, toolchain and operating system should be independent factors, but in practice there's more or less a one-to-one correlation between target operating system and toolchain.</p> <table> <thead> <tr class="header">
*** 279,308 **** </tr> </thead> <tbody> <tr class="odd"> <td style="text-align: left;">Linux</td> ! <td style="text-align: left;">gcc 8.2.0</td> </tr> <tr class="even"> <td style="text-align: left;">macOS</td> ! <td style="text-align: left;">Apple Xcode 10.1 (using clang 10.0.0)</td> </tr> <tr class="odd"> <td style="text-align: left;">Solaris</td> ! <td style="text-align: left;">Oracle Solaris Studio 12.6 (with compiler version 5.15)</td> </tr> <tr class="even"> <td style="text-align: left;">Windows</td> ! <td style="text-align: left;">Microsoft Visual Studio 2017 update 15.9.6</td> </tr> </tbody> </table> - <p>All compilers are expected to be able to compile to the C99 language standard, - as some C99 features are used in the source code. Microsoft Visual Studio - doesn't fully support C99 so in practice shared code is limited to using C99 - features that it does support.</p> <h3 id="gcc">gcc</h3> <p>The minimum accepted version of gcc is 4.8. Older versions will generate a warning by <code>configure</code> and are unlikely to work.</p> <p>The JDK is currently known to be able to compile with at least version 7.4 of gcc.</p> <p>In general, any version between these two should be usable.</p> <h3 id="clang">clang</h3> --- 269,294 ---- </tr> </thead> <tbody> <tr class="odd"> <td style="text-align: left;">Linux</td> ! <td style="text-align: left;">gcc 7.3.0</td> </tr> <tr class="even"> <td style="text-align: left;">macOS</td> ! <td style="text-align: left;">Apple Xcode 9.4 (using clang 9.1.0)</td> </tr> <tr class="odd"> <td style="text-align: left;">Solaris</td> ! <td style="text-align: left;">Oracle Solaris Studio 12.4 (with compiler version 5.13)</td> </tr> <tr class="even"> <td style="text-align: left;">Windows</td> ! <td style="text-align: left;">Microsoft Visual Studio 2017 update 15.5.5</td> </tr> </tbody> </table> <h3 id="gcc">gcc</h3> <p>The minimum accepted version of gcc is 4.8. Older versions will generate a warning by <code>configure</code> and are unlikely to work.</p> <p>The JDK is currently known to be able to compile with at least version 7.4 of gcc.</p> <p>In general, any version between these two should be usable.</p> <h3 id="clang">clang</h3>
*** 371,385 **** <pre><code>$ cc -V cc: Sun C 5.13 SunOS_i386 2014/10/20 $ CC -V CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30</code></pre> <h3 id="microsoft-visual-studio">Microsoft Visual Studio</h3> ! <p>The minimum accepted version of Visual Studio is 2010. Older versions will not be accepted by <code>configure</code>. The maximum accepted version of Visual Studio is 2019. Versions older than 2017 are unlikely to continue working for long.</p> <p>If you have multiple versions of Visual Studio installed, <code>configure</code> will by default pick the latest. You can request a specific version to be used by setting <code>--with-toolchain-version</code>, e.g. <code>--with-toolchain-version=2015</code>.</p> <p>If you get <code>LINK: fatal error LNK1123: failure during conversion to COFF: file invalid</code> when building using Visual Studio 2010, you have encountered <a href="http://support.microsoft.com/kb/2757355">KB2757355</a>, a bug triggered by a specific installation order. However, the solution suggested by the KB article does not always resolve the problem. See <a href="https://stackoverflow.com/questions/10888391">this stackoverflow discussion</a> for other suggestions.</p> <h3 id="ibm-xl-cc">IBM XL C/C++</h3> ! <p>Please consult the AIX section of the <a href="https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms">Supported Build Platforms</a> OpenJDK Build Wiki page for details about which versions of XLC are supported.</p> <h2 id="boot-jdk-requirements">Boot JDK Requirements</h2> <p>Paradoxically, building the JDK requires a pre-existing JDK. This is called the &quot;boot JDK&quot;. The boot JDK does not, however, have to be a JDK built directly from the source code available in the OpenJDK Community. If you are porting the JDK to a new platform, chances are that there already exists another JDK for that platform that is usable as boot JDK.</p> <p>The rule of thumb is that the boot JDK for building JDK major version <em>N</em> should be a JDK of major version <em>N-1</em>, so for building JDK 9 a JDK 8 would be suitable as boot JDK. However, the JDK should be able to &quot;build itself&quot;, so an up-to-date build of the current JDK source is an acceptable alternative. If you are following the <em>N-1</em> rule, make sure you've got the latest update version, since JDK 8 GA might not be able to build JDK 9 on all platforms.</p> <p>Early in the release cycle, version <em>N-1</em> may not yet have been released. In that case, the preferred boot JDK will be version <em>N-2</em> until version <em>N-1</em> is available.</p> <p>If the boot JDK is not automatically detected, or the wrong JDK is picked, use <code>--with-boot-jdk</code> to point to the JDK to use.</p> --- 357,372 ---- <pre><code>$ cc -V cc: Sun C 5.13 SunOS_i386 2014/10/20 $ CC -V CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30</code></pre> <h3 id="microsoft-visual-studio">Microsoft Visual Studio</h3> ! <p>The minimum accepted version of Visual Studio is 2010. Older versions will not be accepted by <code>configure</code>. The maximum accepted version of Visual Studio is 2017. Versions older than 2017 are unlikely to continue working for long.</p> <p>If you have multiple versions of Visual Studio installed, <code>configure</code> will by default pick the latest. You can request a specific version to be used by setting <code>--with-toolchain-version</code>, e.g. <code>--with-toolchain-version=2015</code>.</p> <p>If you get <code>LINK: fatal error LNK1123: failure during conversion to COFF: file invalid</code> when building using Visual Studio 2010, you have encountered <a href="http://support.microsoft.com/kb/2757355">KB2757355</a>, a bug triggered by a specific installation order. However, the solution suggested by the KB article does not always resolve the problem. See <a href="https://stackoverflow.com/questions/10888391">this stackoverflow discussion</a> for other suggestions.</p> <h3 id="ibm-xl-cc">IBM XL C/C++</h3> ! <p>The regular builds by SAP is using version 12.1, described as <code>IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0017</code>.</p> ! <p>See the <a href="http://cr.openjdk.java.net/~simonis/ppc-aix-port">OpenJDK PowerPC Port Status Page</a> for details.</p> <h2 id="boot-jdk-requirements">Boot JDK Requirements</h2> <p>Paradoxically, building the JDK requires a pre-existing JDK. This is called the &quot;boot JDK&quot;. The boot JDK does not, however, have to be a JDK built directly from the source code available in the OpenJDK Community. If you are porting the JDK to a new platform, chances are that there already exists another JDK for that platform that is usable as boot JDK.</p> <p>The rule of thumb is that the boot JDK for building JDK major version <em>N</em> should be a JDK of major version <em>N-1</em>, so for building JDK 9 a JDK 8 would be suitable as boot JDK. However, the JDK should be able to &quot;build itself&quot;, so an up-to-date build of the current JDK source is an acceptable alternative. If you are following the <em>N-1</em> rule, make sure you've got the latest update version, since JDK 8 GA might not be able to build JDK 9 on all platforms.</p> <p>Early in the release cycle, version <em>N-1</em> may not yet have been released. In that case, the preferred boot JDK will be version <em>N-2</em> until version <em>N-1</em> is available.</p> <p>If the boot JDK is not automatically detected, or the wrong JDK is picked, use <code>--with-boot-jdk</code> to point to the JDK to use.</p>
*** 407,419 **** </ul> <p>Use <code>--with-cups=&lt;path&gt;</code> if <code>configure</code> does not properly locate your CUPS files.</p> <h3 id="x11">X11</h3> <p>Certain <a href="http://www.x.org/">X11</a> libraries and include files are required on Linux and Solaris.</p> <ul> ! <li>To install on an apt-based Linux, try running <code>sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev</code>.</li> ! <li>To install on an rpm-based Linux, try running <code>sudo yum install libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel</code>.</li> ! <li>To install on Solaris, try running <code>pkg install x11/header/x11-protocols x11/library/libice x11/library/libpthread-stubs x11/library/libsm x11/library/libx11 x11/library/libxau x11/library/libxcb x11/library/libxdmcp x11/library/libxevie x11/library/libxext x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst x11/library/toolkit/libxt</code>.</li> </ul> <p>Use <code>--with-x=&lt;path&gt;</code> if <code>configure</code> does not properly locate your X11 files.</p> <h3 id="alsa">ALSA</h3> <p>ALSA, <a href="https://www.alsa-project.org/">Advanced Linux Sound Architecture</a> is required on Linux. At least version 0.9.1 of ALSA is required.</p> <ul> --- 394,406 ---- </ul> <p>Use <code>--with-cups=&lt;path&gt;</code> if <code>configure</code> does not properly locate your CUPS files.</p> <h3 id="x11">X11</h3> <p>Certain <a href="http://www.x.org/">X11</a> libraries and include files are required on Linux and Solaris.</p> <ul> ! <li>To install on an apt-based Linux, try running <code>sudo apt-get install libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev</code>.</li> ! <li>To install on an rpm-based Linux, try running <code>sudo yum install libXtst-devel libXt-devel libXrender-devel libXi-devel</code>.</li> ! <li>To install on Solaris, try running <code>pkg install x11/header/x11-protocols x11/library/libice x11/library/libpthread-stubs x11/library/libsm x11/library/libx11 x11/library/libxau x11/library/libxcb x11/library/libxdmcp x11/library/libxevie x11/library/libxext x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst x11/library/toolkit/libxt</code>.</li> </ul> <p>Use <code>--with-x=&lt;path&gt;</code> if <code>configure</code> does not properly locate your X11 files.</p> <h3 id="alsa">ALSA</h3> <p>ALSA, <a href="https://www.alsa-project.org/">Advanced Linux Sound Architecture</a> is required on Linux. At least version 0.9.1 of ALSA is required.</p> <ul>
*** 475,488 **** <li><code>--with-version-&lt;part&gt;=&lt;value&gt;</code> - A group of options, where <code>&lt;part&gt;</code> can be any of <code>pre</code>, <code>opt</code>, <code>build</code>, <code>major</code>, <code>minor</code>, <code>security</code> or <code>patch</code>. Use these options to modify just the corresponding part of the version string from the default, or the value provided by <code>--with-version-string</code>.</li> <li><code>--with-jvm-variants=&lt;variant&gt;[,&lt;variant&gt;...]</code> - Build the specified variant (or variants) of Hotspot. Valid variants are: <code>server</code>, <code>client</code>, <code>minimal</code>, <code>core</code>, <code>zero</code>, <code>custom</code>. Note that not all variants are possible to combine in a single build.</li> <li><code>--with-jvm-features=&lt;feature&gt;[,&lt;feature&gt;...]</code> - Use the specified JVM features when building Hotspot. The list of features will be enabled on top of the default list. For the <code>custom</code> JVM variant, this default list is empty. A complete list of available JVM features can be found using <code>bash configure --help</code>.</li> <li><code>--with-target-bits=&lt;bits&gt;</code> - Create a target binary suitable for running on a <code>&lt;bits&gt;</code> platform. Use this to create 32-bit output on a 64-bit build platform, instead of doing a full cross-compile. (This is known as a <em>reduced</em> build.)</li> </ul> - <p>On Linux, BSD and AIX, it is possible to override where Java by default searches for runtime/JNI libraries. This can be useful in situations where there is a special shared directory for system JNI libraries. This setting can in turn be overriden at runtime by setting the <code>java.library.path</code> property.</p> - <ul> - <li><code>--with-jni-libpath=&lt;path&gt;</code> - Use the specified path as a default when searching for runtime libraries.</li> - </ul> <h4 id="configure-arguments-for-native-compilation">Configure Arguments for Native Compilation</h4> <ul> <li><code>--with-devkit=&lt;path&gt;</code> - Use this devkit for compilers, tools and resources</li> <li><code>--with-sysroot=&lt;path&gt;</code> - Use this directory as sysroot</li> <li><code>--with-extra-path=&lt;path&gt;[;&lt;path&gt;]</code> - Prepend these directories to the default path when searching for all kinds of binaries</li> --- 462,471 ----
*** 499,509 **** <li><code>--with-x=&lt;path&gt;</code> - Set the path to <a href="#x11">X11</a></li> <li><code>--with-alsa=&lt;path&gt;</code> - Set the path to <a href="#alsa">ALSA</a></li> <li><code>--with-libffi=&lt;path&gt;</code> - Set the path to <a href="#libffi">libffi</a></li> <li><code>--with-jtreg=&lt;path&gt;</code> - Set the path to JTReg. See <a href="#running-tests">Running Tests</a></li> </ul> ! <p>Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use the included (&quot;bundled&quot;) versions of libjpeg, giflib, libpng and lcms. For zlib, the system lib (if present) is used except on Windows and AIX. However the bundled libraries may be replaced by an external version. To do so, specify <code>system</code> as the <code>&lt;source&gt;</code> option in these arguments. (The default is <code>bundled</code>).</p> <ul> <li><code>--with-libjpeg=&lt;source&gt;</code> - Use the specified source for libjpeg</li> <li><code>--with-giflib=&lt;source&gt;</code> - Use the specified source for giflib</li> <li><code>--with-libpng=&lt;source&gt;</code> - Use the specified source for libpng</li> <li><code>--with-lcms=&lt;source&gt;</code> - Use the specified source for lcms</li> --- 482,492 ---- <li><code>--with-x=&lt;path&gt;</code> - Set the path to <a href="#x11">X11</a></li> <li><code>--with-alsa=&lt;path&gt;</code> - Set the path to <a href="#alsa">ALSA</a></li> <li><code>--with-libffi=&lt;path&gt;</code> - Set the path to <a href="#libffi">libffi</a></li> <li><code>--with-jtreg=&lt;path&gt;</code> - Set the path to JTReg. See <a href="#running-tests">Running Tests</a></li> </ul> ! <p>Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use this version of these libraries, but they might be replaced by an external version. To do so, specify <code>system</code> as the <code>&lt;source&gt;</code> option in these arguments. (The default is <code>bundled</code>).</p> <ul> <li><code>--with-libjpeg=&lt;source&gt;</code> - Use the specified source for libjpeg</li> <li><code>--with-giflib=&lt;source&gt;</code> - Use the specified source for giflib</li> <li><code>--with-libpng=&lt;source&gt;</code> - Use the specified source for libpng</li> <li><code>--with-lcms=&lt;source&gt;</code> - Use the specified source for lcms</li>
*** 651,667 **** <h4 id="alsa-1">ALSA</h4> <p>You will need alsa libraries suitable for your <em>target</em> system. For most cases, using Debian's pre-built libraries work fine.</p> <p>Note that alsa is needed even if you only want to build a headless JDK.</p> <ul> <li><p>Go to <a href="https://www.debian.org/distrib/packages">Debian Package Search</a> and search for the <code>libasound2</code> and <code>libasound2-dev</code> packages for your <em>target</em> system. Download them to /tmp.</p></li> ! <li>Install the libraries into the cross-compilation toolchain. For instance:</li> ! </ul> <pre><code>cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc dpkg-deb -x /tmp/libasound2_1.0.25-4_armhf.deb . ! dpkg-deb -x /tmp/libasound2-dev_1.0.25-4_armhf.deb .</code></pre> ! <ul> ! <li>If alsa is not properly detected by <code>configure</code>, you can point it out by <code>--with-alsa</code>.</li> </ul> <h4 id="x11-1">X11</h4> <p>You will need X11 libraries suitable for your <em>target</em> system. For most cases, using Debian's pre-built libraries work fine.</p> <p>Note that X11 is needed even if you only want to build a headless JDK.</p> <ul> --- 634,648 ---- <h4 id="alsa-1">ALSA</h4> <p>You will need alsa libraries suitable for your <em>target</em> system. For most cases, using Debian's pre-built libraries work fine.</p> <p>Note that alsa is needed even if you only want to build a headless JDK.</p> <ul> <li><p>Go to <a href="https://www.debian.org/distrib/packages">Debian Package Search</a> and search for the <code>libasound2</code> and <code>libasound2-dev</code> packages for your <em>target</em> system. Download them to /tmp.</p></li> ! <li><p>Install the libraries into the cross-compilation toolchain. For instance:</p> <pre><code>cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc dpkg-deb -x /tmp/libasound2_1.0.25-4_armhf.deb . ! dpkg-deb -x /tmp/libasound2-dev_1.0.25-4_armhf.deb .</code></pre></li> ! <li><p>If alsa is not properly detected by <code>configure</code>, you can point it out by <code>--with-alsa</code>.</p></li> </ul> <h4 id="x11-1">X11</h4> <p>You will need X11 libraries suitable for your <em>target</em> system. For most cases, using Debian's pre-built libraries work fine.</p> <p>Note that X11 is needed even if you only want to build a headless JDK.</p> <ul>
*** 675,685 **** <li>x11proto-render-dev</li> <li>x11proto-xext-dev</li> <li>libice-dev</li> <li>libxrender</li> <li>libxrender-dev</li> - <li>libxrandr-dev</li> <li>libsm-dev</li> <li>libxt-dev</li> <li>libx11</li> <li>libx11-dev</li> <li>libxtst</li> --- 656,665 ----
*** 703,727 **** </ul> <h3 id="creating-and-using-sysroots-with-qemu-deboostrap">Creating And Using Sysroots With qemu-deboostrap</h3> <p>Fortunately, you can create sysroots for foreign architectures with tools provided by your OS. On Debian/Ubuntu systems, one could use <code>qemu-deboostrap</code> to create the <em>target</em> system chroot, which would have the native libraries and headers specific to that <em>target</em> system. After that, we can use the cross-compiler on the <em>build</em> system, pointing into chroot to get the build dependencies right. This allows building for foreign architectures with native compilation speed.</p> <p>For example, cross-compiling to AArch64 from x86_64 could be done like this:</p> <ul> ! <li>Install cross-compiler on the <em>build</em> system:</li> ! </ul> ! <pre><code>apt install g++-aarch64-linux-gnu gcc-aarch64-linux-gnu</code></pre> ! <ul> ! <li>Create chroot on the <em>build</em> system, configuring it for <em>target</em> system:</li> ! </ul> <pre><code>sudo qemu-debootstrap --arch=arm64 --verbose \ ! --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev \ ! --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/</code></pre> ! <ul> ! <li>Configure and build with newly created chroot as sysroot/toolchain-path:</li> ! </ul> <pre><code>CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh ./configure --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/ make images ! ls build/linux-aarch64-normal-server-release/</code></pre> <p>The build does not create new files in that chroot, so it can be reused for multiple builds without additional cleanup.</p> <p>Architectures that are known to successfully cross-compile like this are:</p> <table> <thead> <tr class="header"> --- 683,703 ---- </ul> <h3 id="creating-and-using-sysroots-with-qemu-deboostrap">Creating And Using Sysroots With qemu-deboostrap</h3> <p>Fortunately, you can create sysroots for foreign architectures with tools provided by your OS. On Debian/Ubuntu systems, one could use <code>qemu-deboostrap</code> to create the <em>target</em> system chroot, which would have the native libraries and headers specific to that <em>target</em> system. After that, we can use the cross-compiler on the <em>build</em> system, pointing into chroot to get the build dependencies right. This allows building for foreign architectures with native compilation speed.</p> <p>For example, cross-compiling to AArch64 from x86_64 could be done like this:</p> <ul> ! <li><p>Install cross-compiler on the <em>build</em> system:</p> ! <pre><code>apt install g++-aarch64-linux-gnu gcc-aarch64-linux-gnu</code></pre></li> ! <li><p>Create chroot on the <em>build</em> system, configuring it for <em>target</em> system:</p> <pre><code>sudo qemu-debootstrap --arch=arm64 --verbose \ ! --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev \ ! --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/</code></pre></li> ! <li><p>Configure and build with newly created chroot as sysroot/toolchain-path:</p> <pre><code>CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh ./configure --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/ make images ! ls build/linux-aarch64-normal-server-release/</code></pre></li> ! </ul> <p>The build does not create new files in that chroot, so it can be reused for multiple builds without additional cleanup.</p> <p>Architectures that are known to successfully cross-compile like this are:</p> <table> <thead> <tr class="header">
*** 877,887 **** <pre><code>fatal error - couldn't allocate heap cannot create ... Permission denied spawn failed</code></pre> <p>This can be a sign of a Cygwin problem. See the information about solving problems in the <a href="#cygwin">Cygwin</a> section. Rebooting the computer might help temporarily.</p> <h3 id="getting-help">Getting Help</h3> ! <p>If none of the suggestions in this document helps you, or if you find what you believe is a bug in the build system, please contact the Build Group by sending a mail to <a href="mailto:build-dev@openjdk.java.net">build-dev@openjdk.java.net</a>. Please include the relevant parts of the configure and/or build log.</p> <p>If you need general help or advice about developing for the JDK, you can also contact the Adoption Group. See the section on <a href="#contributing-to-openjdk">Contributing to OpenJDK</a> for more information.</p> <h2 id="hints-and-suggestions-for-advanced-users">Hints and Suggestions for Advanced Users</h2> <h3 id="setting-up-a-repository-for-pushing-changes-defpath">Setting Up a Repository for Pushing Changes (defpath)</h3> <p>To help you prepare a proper push path for a Mercurial repository, there exists a useful tool known as <a href="http://openjdk.java.net/projects/code-tools/defpath">defpath</a>. It will help you setup a proper push path for pushing changes to the JDK.</p> <p>Install the extension by cloning <code>http://hg.openjdk.java.net/code-tools/defpath</code> and updating your <code>.hgrc</code> file. Here's one way to do this:</p> --- 853,868 ---- <pre><code>fatal error - couldn't allocate heap cannot create ... Permission denied spawn failed</code></pre> <p>This can be a sign of a Cygwin problem. See the information about solving problems in the <a href="#cygwin">Cygwin</a> section. Rebooting the computer might help temporarily.</p> <h3 id="getting-help">Getting Help</h3> ! <p>If none of the suggestions in this document helps you, or if you find what you believe is a bug in the build system, please contact the Build Group by sending a mail to <script type="text/javascript"> ! <!-- ! h='openjdk.java.net';a='@';n='build-dev';e=n+a+h; ! document.write('<a h'+'ref'+'="ma'+'ilto'+':'+e+'" clas'+'s="em' + 'ail">'+e+'<\/'+'a'+'>'); ! // --> ! </script><noscript>build-dev at openjdk dot java dot net</noscript>. Please include the relevant parts of the configure and/or build log.</p> <p>If you need general help or advice about developing for the JDK, you can also contact the Adoption Group. See the section on <a href="#contributing-to-openjdk">Contributing to OpenJDK</a> for more information.</p> <h2 id="hints-and-suggestions-for-advanced-users">Hints and Suggestions for Advanced Users</h2> <h3 id="setting-up-a-repository-for-pushing-changes-defpath">Setting Up a Repository for Pushing Changes (defpath)</h3> <p>To help you prepare a proper push path for a Mercurial repository, there exists a useful tool known as <a href="http://openjdk.java.net/projects/code-tools/defpath">defpath</a>. It will help you setup a proper push path for pushing changes to the JDK.</p> <p>Install the extension by cloning <code>http://hg.openjdk.java.net/code-tools/defpath</code> and updating your <code>.hgrc</code> file. Here's one way to do this:</p>
< prev index next >