< prev index next >

doc/building.md

Print this page

        

*** 73,84 **** 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. ! * On Windows, if using [Cygwin](#cygwin), extra care must be taken to make sure ! the environment is consistent. It is recommended that you follow this procedure: * Create the directory that is going to contain the top directory of the JDK clone by using the `mkdir` command in the Cygwin bash shell. That is, do *not* create it using Windows Explorer. This will ensure --- 73,84 ---- 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. ! * On Windows, extra care must be taken to make sure the [Cygwin](#cygwin) ! environment is consistent. It is recommended that you follow this procedure: * Create the directory that is going to contain the top directory of the JDK clone by using the `mkdir` command in the Cygwin bash shell. That is, do *not* create it using Windows Explorer. This will ensure
*** 148,165 **** information is always subject to change, but this table is up to date at the time of writing. Operating system Vendor/version used ----------------- ------------------------------------------------------- ! Linux Oracle Enterprise Linux 6.4 / 7.6 ! Solaris Solaris 11.3 SRU 20 ! macOS Mac OS X 10.13 (High Sierra) Windows Windows Server 2012 R2 ! 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. The Build Group has a wiki page with [Supported Build Platforms]( https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From time to time, this is updated by contributors to list successes or failures of building on different platforms. --- 148,165 ---- information is always subject to change, but this table is up to date at the time of writing. Operating system Vendor/version used ----------------- ------------------------------------------------------- ! Linux Oracle Enterprise Linux 6.4 / 7.1 (using kernel 3.8.13) ! Solaris Solaris 11.1 SRU 21.4.1 / 11.2 SRU 5.5 ! macOS Mac OS X 10.9 (Mavericks) / 10.10 (Yosemite) Windows Windows Server 2012 R2 ! 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. The Build Group has a wiki page with [Supported Build Platforms]( https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From time to time, this is updated by contributors to list successes or failures of building on different platforms.
*** 172,206 **** On Windows, it is important that you pay attention to the instructions in the [Special Considerations](#special-considerations). 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.) Internally in the build system, all paths are represented as Unix-style paths, e.g. `/cygdrive/c/hg/jdk9/Makefile` rather than `C:\hg\jdk9\Makefile`. This rule also applies to input to the build system, e.g. in arguments to `configure`. So, use `--with-msvcr-dll=/cygdrive/c/msvcr100.dll` rather than `--with-msvcr-dll=c:\msvcr100.dll`. For details on this conversion, see the section on [Fixpath](#fixpath). #### Cygwin ! A functioning [Cygwin](http://www.cygwin.com/) 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. **Note:** 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. ! 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. Apart from the basic Cygwin installation, the following packages must also be installed: --- 172,206 ---- On Windows, it is important that you pay attention to the instructions in the [Special Considerations](#special-considerations). 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.) Internally in the build system, all paths are represented as Unix-style paths, e.g. `/cygdrive/c/hg/jdk9/Makefile` rather than `C:\hg\jdk9\Makefile`. This rule also applies to input to the build system, e.g. in arguments to `configure`. So, use `--with-msvcr-dll=/cygdrive/c/msvcr100.dll` rather than `--with-msvcr-dll=c:\msvcr100.dll`. For details on this conversion, see the section on [Fixpath](#fixpath). #### Cygwin ! A functioning [Cygwin](http://www.cygwin.com/) 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. **Note:** 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. ! 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. Apart from the basic Cygwin installation, the following packages must also be installed:
*** 219,252 **** experience build tool crashes or strange issues when building on Windows, please check the Cygwin FAQ on the ["BLODA" list]( https://cygwin.com/faq/faq.html#faq.using.bloda) and the section on [fork() failures](https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures). - #### Windows Subsystem for Linux (WSL) - - 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. - - 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 - `--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu` to - `configure`. - - 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. - - Note that while it's possible to build on WSL, testing is still not fully - supported. - ### Solaris See `make/devkit/solaris11.1-package-list.txt` 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 --- 219,228 ----
*** 293,305 **** sudo yum groupinstall "Development Tools" ``` ### AIX ! Please consult the AIX section of the [Supported Build Platforms]( ! https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK ! Build Wiki page for details about which versions of AIX are supported. ## Native Compiler (Toolchain) Requirements 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 --- 269,281 ---- sudo yum groupinstall "Development Tools" ``` ### AIX ! The regular builds by SAP is using AIX version 7.1, but AIX 5.3 is also ! supported. See the [OpenJDK PowerPC Port Status Page]( ! http://cr.openjdk.java.net/~simonis/ppc-aix-port) for details. ## Native Compiler (Toolchain) Requirements 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
*** 321,339 **** you stay to this list, the more likely you are to compile successfully without issues. Operating system Toolchain version ------------------ ------------------------------------------------------- ! Linux gcc 8.2.0 ! macOS Apple Xcode 10.1 (using clang 10.0.0) ! Solaris Oracle Solaris Studio 12.6 (with compiler version 5.15) ! Windows Microsoft Visual Studio 2017 update 15.9.6 ! ! 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. ### gcc The minimum accepted version of gcc is 4.8. Older versions will generate a warning by `configure` and are unlikely to work. --- 297,310 ---- you stay to this list, the more likely you are to compile successfully without issues. Operating system Toolchain version ------------------ ------------------------------------------------------- ! Linux gcc 7.3.0 ! macOS Apple Xcode 9.4 (using clang 9.1.0) ! Solaris Oracle Solaris Studio 12.4 (with compiler version 5.13) ! Windows Microsoft Visual Studio 2017 update 15.5.5 ### gcc The minimum accepted version of gcc is 4.8. Older versions will generate a warning by `configure` and are unlikely to work.
*** 407,417 **** ### Microsoft Visual Studio The minimum accepted version of Visual Studio is 2010. Older versions will not be accepted by `configure`. The maximum accepted version of Visual Studio is ! 2019. Versions older than 2017 are unlikely to continue working for long. If you have multiple versions of Visual Studio installed, `configure` will by default pick the latest. You can request a specific version to be used by setting `--with-toolchain-version`, e.g. `--with-toolchain-version=2015`. --- 378,388 ---- ### Microsoft Visual Studio The minimum accepted version of Visual Studio is 2010. Older versions will not be accepted by `configure`. The maximum accepted version of Visual Studio is ! 2017. Versions older than 2017 are unlikely to continue working for long. If you have multiple versions of Visual Studio installed, `configure` will by default pick the latest. You can request a specific version to be used by setting `--with-toolchain-version`, e.g. `--with-toolchain-version=2015`.
*** 422,435 **** does not always resolve the problem. See [this stackoverflow discussion]( https://stackoverflow.com/questions/10888391) for other suggestions. ### IBM XL C/C++ ! Please consult the AIX section of the [Supported Build Platforms]( ! https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK ! Build Wiki page for details about which versions of XLC are supported. ## Boot JDK Requirements Paradoxically, building the JDK requires a pre-existing JDK. This is called the "boot JDK". The boot JDK does not, however, have to be a JDK built directly from --- 393,407 ---- does not always resolve the problem. See [this stackoverflow discussion]( https://stackoverflow.com/questions/10888391) for other suggestions. ### IBM XL C/C++ ! The regular builds by SAP is using version 12.1, described as `IBM XL C/C++ for ! AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0017`. + See the [OpenJDK PowerPC Port Status Page]( + http://cr.openjdk.java.net/~simonis/ppc-aix-port) for details. ## Boot JDK Requirements Paradoxically, building the JDK requires a pre-existing JDK. This is called the "boot JDK". The boot JDK does not, however, have to be a JDK built directly from
*** 514,532 **** Certain [X11](http://www.x.org/) libraries and include files are required on Linux and Solaris. * To install on an apt-based Linux, try running `sudo apt-get install ! libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`. * To install on an rpm-based Linux, try running `sudo yum install ! libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`. * To install on Solaris, try running `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`. Use `--with-x=<path>` if `configure` does not properly locate your X11 files. ### ALSA --- 486,504 ---- Certain [X11](http://www.x.org/) libraries and include files are required on Linux and Solaris. * To install on an apt-based Linux, try running `sudo apt-get install ! libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`. * To install on an rpm-based Linux, try running `sudo yum install ! libXtst-devel libXt-devel libXrender-devel libXi-devel`. * To install on Solaris, try running `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`. Use `--with-x=<path>` if `configure` does not properly locate your X11 files. ### ALSA
*** 688,705 **** * `--with-target-bits=<bits>` - Create a target binary suitable for running on a `<bits>` 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 *reduced* build.) - 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 `java.library.path` property. - - * `--with-jni-libpath=<path>` - Use the specified path as a default - when searching for runtime libraries. - #### Configure Arguments for Native Compilation * `--with-devkit=<path>` - Use this devkit for compilers, tools and resources * `--with-sysroot=<path>` - Use this directory as sysroot * `--with-extra-path=<path>[;<path>]` - Prepend these directories to the --- 660,669 ----
*** 725,740 **** * `--with-jtreg=<path>` - Set the path to JTReg. See [Running Tests]( #running-tests) 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 ("bundled") 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 `system` as the `<source>` option in these arguments. ! (The default is `bundled`). * `--with-libjpeg=<source>` - Use the specified source for libjpeg * `--with-giflib=<source>` - Use the specified source for giflib * `--with-libpng=<source>` - Use the specified source for libpng * `--with-lcms=<source>` - Use the specified source for lcms --- 689,701 ---- * `--with-jtreg=<path>` - Set the path to JTReg. See [Running Tests]( #running-tests) 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 `system` as the `<source>` ! option in these arguments. (The default is `bundled`). * `--with-libjpeg=<source>` - Use the specified source for libjpeg * `--with-giflib=<source>` - Use the specified source for giflib * `--with-libpng=<source>` - Use the specified source for libpng * `--with-lcms=<source>` - Use the specified source for lcms
*** 947,957 **** https://sourceware.org/autobook/autobook/autobook_17.html). If no targets are given, a native toolchain for the current platform will be created. Currently, at least the following targets are known to work: Supported devkit targets ! ------------------------- x86_64-linux-gnu aarch64-linux-gnu arm-linux-gnueabihf ppc64-linux-gnu ppc64le-linux-gnu --- 908,918 ---- https://sourceware.org/autobook/autobook/autobook_17.html). If no targets are given, a native toolchain for the current platform will be created. Currently, at least the following targets are known to work: Supported devkit targets ! ------------------------ x86_64-linux-gnu aarch64-linux-gnu arm-linux-gnueabihf ppc64-linux-gnu ppc64le-linux-gnu
*** 1091,1101 **** * x11proto-render-dev * x11proto-xext-dev * libice-dev * libxrender * libxrender-dev - * libxrandr-dev * libsm-dev * libxt-dev * libx11 * libx11-dev * libxtst --- 1052,1061 ----
*** 1142,1152 **** ``` * Create chroot on the *build* system, configuring it for *target* system: ``` 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/ ``` * Configure and build with newly created chroot as sysroot/toolchain-path: ``` --- 1102,1112 ---- ``` * Create chroot on the *build* system, configuring it for *target* system: ``` 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/ ``` * Configure and build with newly created chroot as sysroot/toolchain-path: ```
*** 1158,1174 **** The build does not create new files in that chroot, so it can be reused for multiple builds without additional cleanup. Architectures that are known to successfully cross-compile like this are: ! Target `CC` `CXX` `--arch=...` `--openjdk-target=...` ! ------------ ------------------------- --------------------------- ------------- ----------------------- ! x86 default default i386 i386-linux-gnu ! armhf gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf armhf arm-linux-gnueabihf ! aarch64 gcc-aarch64-linux-gnu g++-aarch64-linux-gnu arm64 aarch64-linux-gnu ! ppc64el gcc-powerpc64le-linux-gnu g++-powerpc64le-linux-gnu ppc64el powerpc64le-linux-gnu ! s390x gcc-s390x-linux-gnu g++-s390x-linux-gnu s390x s390x-linux-gnu Additional architectures might be supported by Debian/Ubuntu Ports. ### Building for ARM/aarch64 --- 1118,1134 ---- The build does not create new files in that chroot, so it can be reused for multiple builds without additional cleanup. Architectures that are known to successfully cross-compile like this are: ! Target `CC` `CXX` `--arch=...` `--openjdk-target=...` ! ------------ ------------------------- --------------------------- ------------ ---------------------- ! x86 default default i386 i386-linux-gnu ! armhf gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf armhf arm-linux-gnueabihf ! aarch64 gcc-aarch64-linux-gnu g++-aarch64-linux-gnu arm64 aarch64-linux-gnu ! ppc64el gcc-powerpc64le-linux-gnu g++-powerpc64le-linux-gnu ppc64el powerpc64le-linux-gnu ! s390x gcc-s390x-linux-gnu g++-s390x-linux-gnu s390x s390x-linux-gnu Additional architectures might be supported by Debian/Ubuntu Ports. ### Building for ARM/aarch64
< prev index next >