< prev index next >

doc/building.md

Print this page




  58 
  59 ### Special Considerations
  60 
  61 For a smooth building experience, it is recommended that you follow these rules
  62 on where and how to check out the source code.
  63 
  64   * Do not check out the source code in a path which contains spaces. Chances
  65     are the build will not work. This is most likely to be an issue on Windows
  66     systems.
  67 
  68   * Do not check out the source code in a path which has a very long name or is
  69     nested many levels deep. Chances are you will hit an OS limitation during
  70     the build.
  71 
  72   * Put the source code on a local disk, not a network share. If possible, use
  73     an SSD. The build process is very disk intensive, and having slow disk
  74     access will significantly increase build times. If you need to use a
  75     network share for the source code, see below for suggestions on how to keep
  76     the build artifacts on a local disk.
  77 
  78   * On Windows, if using [Cygwin](#cygwin), extra care must be taken to make sure
  79     the environment is consistent. It is recommended that you follow this
  80     procedure:
  81 
  82       * Create the directory that is going to contain the top directory of the
  83         JDK clone by using the `mkdir` command in the Cygwin bash shell.
  84         That is, do *not* create it using Windows Explorer. This will ensure
  85         that it will have proper Cygwin attributes, and that it's children will
  86         inherit those attributes.
  87 
  88       * Do not put the JDK clone in a path under your Cygwin home
  89         directory. This is especially important if your user name contains
  90         spaces and/or mixed upper and lower case letters.
  91 
  92       * Clone the JDK repository using the Cygwin command line `hg` client
  93         as instructed in this document. That is, do *not* use another Mercurial
  94         client such as TortoiseHg.
  95 
  96     Failure to follow this procedure might result in hard-to-debug build
  97     problems.
  98 
  99 ## Build Hardware Requirements


 133 
 134 This is not recommended. Instead, see the section on [Cross-compiling](
 135 #cross-compiling).
 136 
 137 ## Operating System Requirements
 138 
 139 The mainline JDK project supports Linux, Solaris, macOS, AIX and Windows.
 140 Support for other operating system, e.g. BSD, exists in separate "port"
 141 projects.
 142 
 143 In general, the JDK can be built on a wide range of versions of these operating
 144 systems, but the further you deviate from what is tested on a daily basis, the
 145 more likely you are to run into problems.
 146 
 147 This table lists the OS versions used by Oracle when building the JDK. Such
 148 information is always subject to change, but this table is up to date at the
 149 time of writing.
 150 
 151  Operating system   Vendor/version used
 152  -----------------  -------------------------------------------------------
 153  Linux              Oracle Enterprise Linux 6.4 / 7.6
 154  Solaris            Solaris 11.3 SRU 20
 155  macOS              Mac OS X 10.13 (High Sierra)
 156  Windows            Windows Server 2012 R2
 157 
 158 The double version numbers for Linux and Solaris are due to the hybrid model
 159 used at Oracle, where header files and external libraries from an older version
 160 are used when building on a more modern version of the OS.
 161 
 162 The Build Group has a wiki page with [Supported Build Platforms](
 163 https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From
 164 time to time, this is updated by contributors to list successes or failures of
 165 building on different platforms.
 166 
 167 ### Windows
 168 
 169 Windows XP is not a supported platform, but all newer Windows should be able to
 170 build the JDK.
 171 
 172 On Windows, it is important that you pay attention to the instructions in the
 173 [Special Considerations](#special-considerations).
 174 
 175 Windows is the only non-POSIX OS supported by the JDK, and as such, requires
 176 some extra care. A POSIX support layer is required to build on Windows.
 177 Currently, the only supported such layers are Cygwin and Windows Subsystem for
 178 Linux (WSL). (Msys is no longer supported due to a too old bash; msys2 would
 179 likely be possible to support in a future version but that would require effort
 180 to implement.)
 181 
 182 Internally in the build system, all paths are represented as Unix-style paths,
 183 e.g. `/cygdrive/c/hg/jdk9/Makefile` rather than `C:\hg\jdk9\Makefile`. This
 184 rule also applies to input to the build system, e.g. in arguments to
 185 `configure`. So, use `--with-msvcr-dll=/cygdrive/c/msvcr100.dll` rather than
 186 `--with-msvcr-dll=c:\msvcr100.dll`. For details on this conversion, see the section
 187 on [Fixpath](#fixpath).
 188 
 189 #### Cygwin
 190 
 191 A functioning [Cygwin](http://www.cygwin.com/) environment is required for
 192 building the JDK on Windows. If you have a 64-bit OS, we strongly recommend
 193 using the 64-bit version of Cygwin.
 194 
 195 **Note:** Cygwin has a model of continuously updating all packages without any
 196 easy way to install or revert to a specific version of a package. This means
 197 that whenever you add or update a package in Cygwin, you might (inadvertently)
 198 update tools that are used by the JDK build process, and that can cause
 199 unexpected build problems.
 200 
 201 The JDK requires GNU Make 4.0 or greater in Cygwin. This is usually not a
 202 problem, since Cygwin currently only distributes GNU Make at a version above
 203 4.0.
 204 
 205 Apart from the basic Cygwin installation, the following packages must also be
 206 installed:
 207 
 208   * `autoconf`
 209   * `make`
 210   * `zip`
 211   * `unzip`
 212 
 213 Often, you can install these packages using the following command line:
 214 ```
 215 <path to Cygwin setup>/setup-x86_64 -q -P autoconf -P make -P unzip -P zip
 216 ```
 217 
 218 Unfortunately, Cygwin can be unreliable in certain circumstances. If you
 219 experience build tool crashes or strange issues when building on Windows,
 220 please check the Cygwin FAQ on the ["BLODA" list](
 221 https://cygwin.com/faq/faq.html#faq.using.bloda) and the section on [fork()
 222 failures](https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures).
 223 
 224 #### Windows Subsystem for Linux (WSL)
 225 
 226 Windows 10 1809 or newer is supported due to a dependency on the wslpath utility
 227 and support for environment variable sharing through WSLENV. Version 1803 can
 228 work but intermittent build failures have been observed.
 229 
 230 It's possible to build both Windows and Linux binaries from WSL. To build
 231 Windows binaries, you must use a Windows boot JDK (located in a
 232 Windows-accessible directory). To build Linux binaries, you must use a Linux
 233 boot JDK. The default behavior is to build for Windows. To build for Linux, pass
 234 `--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu` to
 235 `configure`.
 236 
 237 If building Windows binaries, the source code must be located in a Windows-
 238 accessible directory. This is because Windows executables (such as Visual Studio
 239 and the boot JDK) must be able to access the source code. Also, the drive where
 240 the source is stored must be mounted as case-insensitive by changing either
 241 /etc/fstab or /etc/wsl.conf in WSL. Individual directories may be corrected
 242 using the fsutil tool in case the source was cloned before changing the mount
 243 options.
 244 
 245 Note that while it's possible to build on WSL, testing is still not fully
 246 supported.
 247 
 248 ### Solaris
 249 
 250 See `make/devkit/solaris11.1-package-list.txt` for a list of recommended
 251 packages to install when building on Solaris. The versions specified in this
 252 list is the versions used by the daily builds at Oracle, and is likely to work
 253 properly.
 254 
 255 Older versions of Solaris shipped a broken version of `objcopy`. At least
 256 version 2.21.1 is needed, which is provided by Solaris 11 Update 1. Objcopy is
 257 needed if you want to have external debug symbols. Please make sure you are
 258 using at least version 2.21.1 of objcopy, or that you disable external debug
 259 symbols.
 260 
 261 ### macOS
 262 
 263 Apple is using a quite aggressive scheme of pushing OS updates, and coupling
 264 these updates with required updates of Xcode. Unfortunately, this makes it
 265 difficult for a project such as the JDK to keep pace with a continuously updated
 266 machine running macOS. See the section on [Apple Xcode](#apple-xcode) on some
 267 strategies to deal with this.


 278 
 279 It is often not much problem to build the JDK on Linux. The only general advice
 280 is to try to use the compilers, external libraries and header files as provided
 281 by your distribution.
 282 
 283 The basic tooling is provided as part of the core operating system, but you
 284 will most likely need to install developer packages.
 285 
 286 For apt-based distributions (Debian, Ubuntu, etc), try this:
 287 ```
 288 sudo apt-get install build-essential
 289 ```
 290 
 291 For rpm-based distributions (Fedora, Red Hat, etc), try this:
 292 ```
 293 sudo yum groupinstall "Development Tools"
 294 ```
 295 
 296 ### AIX
 297 
 298 Please consult the AIX section of the [Supported Build Platforms](
 299 https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK
 300 Build Wiki page for details about which versions of AIX are supported.
 301 
 302 ## Native Compiler (Toolchain) Requirements
 303 
 304 Large portions of the JDK consists of native code, that needs to be compiled to
 305 be able to run on the target platform. In theory, toolchain and operating
 306 system should be independent factors, but in practice there's more or less a
 307 one-to-one correlation between target operating system and toolchain.
 308 
 309  Operating system   Supported toolchain
 310  ------------------ -------------------------
 311  Linux              gcc, clang
 312  macOS              Apple Xcode (using clang)
 313  Solaris            Oracle Solaris Studio
 314  AIX                IBM XL C/C++
 315  Windows            Microsoft Visual Studio
 316 
 317 Please see the individual sections on the toolchains for version
 318 recommendations. As a reference, these versions of the toolchains are used, at
 319 the time of writing, by Oracle for the daily builds of the JDK. It should be
 320 possible to compile the JDK with both older and newer versions, but the closer
 321 you stay to this list, the more likely you are to compile successfully without
 322 issues.
 323 
 324  Operating system   Toolchain version
 325  ------------------ -------------------------------------------------------
 326  Linux              gcc 8.2.0
 327  macOS              Apple Xcode 10.1 (using clang 10.0.0)
 328  Solaris            Oracle Solaris Studio 12.6 (with compiler version 5.15)
 329  Windows            Microsoft Visual Studio 2017 update 15.9.6
 330 
 331 All compilers are expected to be able to compile to the C99 language standard,
 332 as some C99 features are used in the source code. Microsoft Visual Studio
 333 doesn't fully support C99 so in practice shared code is limited to using C99
 334 features that it does support.
 335 
 336 ### gcc
 337 
 338 The minimum accepted version of gcc is 4.8. Older versions will generate a warning
 339 by `configure` and are unlikely to work.
 340 
 341 The JDK is currently known to be able to compile with at least version 7.4 of
 342 gcc.
 343 
 344 In general, any version between these two should be usable.
 345 
 346 ### clang
 347 
 348 The minimum accepted version of clang is 3.2. Older versions will not be
 349 accepted by `configure`.
 350 
 351 To use clang instead of gcc on Linux, use `--with-toolchain-type=clang`.
 352 
 353 ### Apple Xcode
 354 


 392  developer/solarisstudio-124/library/math-libs      12.4-1.0.0.1
 393  developer/solarisstudio-124/library/studio-gccrt   12.4-1.0.0.1
 394  developer/solarisstudio-124/studio-common          12.4-1.0.0.1
 395  developer/solarisstudio-124/studio-ja              12.4-1.0.0.1
 396  developer/solarisstudio-124/studio-legal           12.4-1.0.0.1
 397  developer/solarisstudio-124/studio-zhCN            12.4-1.0.0.1
 398 
 399 Compiling with Solaris Studio can sometimes be finicky. This is the exact
 400 version used by Oracle, which worked correctly at the time of writing:
 401 ```
 402 $ cc -V
 403 cc: Sun C 5.13 SunOS_i386 2014/10/20
 404 $ CC -V
 405 CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30
 406 ```
 407 
 408 ### Microsoft Visual Studio
 409 
 410 The minimum accepted version of Visual Studio is 2010. Older versions will not
 411 be accepted by `configure`. The maximum accepted version of Visual Studio is
 412 2019. Versions older than 2017 are unlikely to continue working for long.
 413 
 414 If you have multiple versions of Visual Studio installed, `configure` will by
 415 default pick the latest. You can request a specific version to be used by
 416 setting `--with-toolchain-version`, e.g. `--with-toolchain-version=2015`.
 417 
 418 If you get `LINK: fatal error LNK1123: failure during conversion to COFF: file
 419 invalid` when building using Visual Studio 2010, you have encountered
 420 [KB2757355](http://support.microsoft.com/kb/2757355), a bug triggered by a
 421 specific installation order. However, the solution suggested by the KB article
 422 does not always resolve the problem. See [this stackoverflow discussion](
 423 https://stackoverflow.com/questions/10888391) for other suggestions.
 424 
 425 ### IBM XL C/C++
 426 
 427 Please consult the AIX section of the [Supported Build Platforms](
 428 https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK
 429 Build Wiki page for details about which versions of XLC are supported.
 430 


 431 
 432 ## Boot JDK Requirements
 433 
 434 Paradoxically, building the JDK requires a pre-existing JDK. This is called the
 435 "boot JDK". The boot JDK does not, however, have to be a JDK built directly from
 436 the source code available in the OpenJDK Community.  If you are porting the JDK
 437 to a new platform, chances are that there already exists another JDK for that
 438 platform that is usable as boot JDK.
 439 
 440 The rule of thumb is that the boot JDK for building JDK major version *N*
 441 should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 would be
 442 suitable as boot JDK. However, the JDK should be able to "build itself", so an
 443 up-to-date build of the current JDK source is an acceptable alternative. If
 444 you are following the *N-1* rule, make sure you've got the latest update
 445 version, since JDK 8 GA might not be able to build JDK 9 on all platforms.
 446 
 447 Early in the release cycle, version *N-1* may not yet have been released. In
 448 that case, the preferred boot JDK will be version *N-2* until version *N-1*
 449 is available.
 450 


 499 
 500 CUPS, [Common UNIX Printing System](http://www.cups.org) header files are
 501 required on all platforms, except Windows. Often these files are provided by
 502 your operating system.
 503 
 504   * To install on an apt-based Linux, try running `sudo apt-get install
 505     libcups2-dev`.
 506   * To install on an rpm-based Linux, try running `sudo yum install
 507     cups-devel`.
 508   * To install on Solaris, try running `pkg install print/cups`.
 509 
 510 Use `--with-cups=<path>` if `configure` does not properly locate your CUPS
 511 files.
 512 
 513 ### X11
 514 
 515 Certain [X11](http://www.x.org/) libraries and include files are required on
 516 Linux and Solaris.
 517 
 518   * To install on an apt-based Linux, try running `sudo apt-get install
 519     libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
 520   * To install on an rpm-based Linux, try running `sudo yum install
 521     libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
 522   * To install on Solaris, try running `pkg install x11/header/x11-protocols
 523     x11/library/libice x11/library/libpthread-stubs x11/library/libsm
 524     x11/library/libx11 x11/library/libxau x11/library/libxcb
 525     x11/library/libxdmcp x11/library/libxevie x11/library/libxext
 526     x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
 527     x11/library/libxtst x11/library/toolkit/libxt`.
 528 
 529 Use `--with-x=<path>` if `configure` does not properly locate your X11 files.
 530 
 531 ### ALSA
 532 
 533 ALSA, [Advanced Linux Sound Architecture](https://www.alsa-project.org/) is
 534 required on Linux. At least version 0.9.1 of ALSA is required.
 535 
 536   * To install on an apt-based Linux, try running `sudo apt-get install
 537     libasound2-dev`.
 538   * To install on an rpm-based Linux, try running `sudo yum install
 539     alsa-lib-devel`.
 540 
 541 Use `--with-alsa=<path>` if `configure` does not properly locate your ALSA
 542 files.
 543 
 544 ### libffi
 545 
 546 libffi, the [Portable Foreign Function Interface Library](
 547 http://sourceware.org/libffi) is required when building the Zero version of


 673   * `--with-version-string=<string>` - Specify the version string this build
 674     will be identified with.
 675   * `--with-version-<part>=<value>` - A group of options, where `<part>` can be
 676     any of `pre`, `opt`, `build`, `major`, `minor`, `security` or `patch`. Use
 677     these options to modify just the corresponding part of the version string
 678     from the default, or the value provided by `--with-version-string`.
 679   * `--with-jvm-variants=<variant>[,<variant>...]` - Build the specified variant
 680     (or variants) of Hotspot. Valid variants are: `server`, `client`,
 681     `minimal`, `core`, `zero`, `custom`. Note that not all
 682     variants are possible to combine in a single build.
 683   * `--with-jvm-features=<feature>[,<feature>...]` - Use the specified JVM
 684     features when building Hotspot. The list of features will be enabled on top
 685     of the default list. For the `custom` JVM variant, this default list is
 686     empty. A complete list of available JVM features can be found using `bash
 687     configure --help`.
 688   * `--with-target-bits=<bits>` - Create a target binary suitable for running
 689     on a `<bits>` platform. Use this to create 32-bit output on a 64-bit build
 690     platform, instead of doing a full cross-compile. (This is known as a
 691     *reduced* build.)
 692 
 693 On Linux, BSD and AIX, it is possible to override where Java by default
 694 searches for runtime/JNI libraries. This can be useful in situations where
 695 there is a special shared directory for system JNI libraries. This setting
 696 can in turn be overriden at runtime by setting the `java.library.path` property.
 697 
 698   * `--with-jni-libpath=<path>` - Use the specified path as a default
 699   when searching for runtime libraries.
 700 
 701 #### Configure Arguments for Native Compilation
 702 
 703   * `--with-devkit=<path>` - Use this devkit for compilers, tools and resources
 704   * `--with-sysroot=<path>` - Use this directory as sysroot
 705   * `--with-extra-path=<path>[;<path>]` - Prepend these directories to the
 706     default path when searching for all kinds of binaries
 707   * `--with-toolchain-path=<path>[;<path>]` - Prepend these directories when
 708     searching for toolchain binaries (compilers etc)
 709   * `--with-extra-cflags=<flags>` - Append these flags when compiling JDK C
 710     files
 711   * `--with-extra-cxxflags=<flags>` - Append these flags when compiling JDK C++
 712     files
 713   * `--with-extra-ldflags=<flags>` - Append these flags when linking JDK
 714     libraries
 715 
 716 #### Configure Arguments for External Dependencies
 717 
 718   * `--with-boot-jdk=<path>` - Set the path to the [Boot JDK](
 719     #boot-jdk-requirements)
 720   * `--with-freetype=<path>` - Set the path to [FreeType](#freetype)
 721   * `--with-cups=<path>` - Set the path to [CUPS](#cups)
 722   * `--with-x=<path>` - Set the path to [X11](#x11)
 723   * `--with-alsa=<path>` - Set the path to [ALSA](#alsa)
 724   * `--with-libffi=<path>` - Set the path to [libffi](#libffi)
 725   * `--with-jtreg=<path>` - Set the path to JTReg. See [Running Tests](
 726     #running-tests)
 727 
 728 Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms
 729 and zlib) are included in the JDK repository. The default behavior of the
 730 JDK build is to use the included ("bundled") versions of libjpeg, giflib,
 731 libpng and lcms.
 732 For zlib, the system lib (if present) is used except on Windows and AIX.
 733 However the bundled libraries may be replaced by an external version.
 734 To do so, specify `system` as the `<source>` option in these arguments.
 735 (The default is `bundled`).
 736 
 737   * `--with-libjpeg=<source>` - Use the specified source for libjpeg
 738   * `--with-giflib=<source>` - Use the specified source for giflib
 739   * `--with-libpng=<source>` - Use the specified source for libpng
 740   * `--with-lcms=<source>` - Use the specified source for lcms
 741   * `--with-zlib=<source>` - Use the specified source for zlib
 742 
 743 On Linux, it is possible to select either static or dynamic linking of the C++
 744 runtime. The default is static linking, with dynamic linking as fallback if the
 745 static library is not found.
 746 
 747   * `--with-stdc++lib=<method>` - Use the specified method (`static`, `dynamic`
 748     or `default`) for linking the C++ runtime.
 749 
 750 ### Configure Control Variables
 751 
 752 It is possible to control certain aspects of `configure` by overriding the
 753 value of `configure` variables, either on the command line or in the
 754 environment.
 755 


 932 the following command:
 933 ```
 934 bash configure --with-devkit=<devkit-path> --openjdk-target=ppc64-linux-gnu && make
 935 ```
 936 
 937 will configure and build OpenJDK for Linux/ppc64 assuming that `<devkit-path>`
 938 points to a Linux/x86_64 to Linux/ppc64 devkit.
 939 
 940 Devkits can be created from the `make/devkit` directory by executing:
 941 ```
 942 make [ TARGETS="<TARGET_TRIPLET>+" ] [ BASE_OS=<OS> ] [ BASE_OS_VERSION=<VER> ]
 943 ```
 944 
 945 where `TARGETS` contains one or more `TARGET_TRIPLET`s of the form
 946 described in [section 3.4 of the GNU Autobook](
 947 https://sourceware.org/autobook/autobook/autobook_17.html). If no
 948 targets are given, a native toolchain for the current platform will be
 949 created. Currently, at least the following targets are known to work:
 950 
 951  Supported devkit targets
 952  -------------------------
 953  x86_64-linux-gnu
 954  aarch64-linux-gnu
 955  arm-linux-gnueabihf
 956  ppc64-linux-gnu
 957  ppc64le-linux-gnu
 958  s390x-linux-gnu
 959 
 960 `BASE_OS` must be one of "OEL6" for Oracle Enterprise Linux 6 or
 961 "Fedora" (if not specified "OEL6" will be the default). If the base OS
 962 is "Fedora" the corresponding Fedora release can be specified with the
 963 help of the `BASE_OS_VERSION` option (with "27" as default version).
 964 If the build is successful, the new devkits can be found in the
 965 `build/devkit/result` subdirectory:
 966 ```
 967 cd make/devkit
 968 make TARGETS="ppc64le-linux-gnu aarch64-linux-gnu" BASE_OS=Fedora BASE_OS_VERSION=21
 969 ls -1 ../../build/devkit/result/
 970 x86_64-linux-gnu-to-aarch64-linux-gnu
 971 x86_64-linux-gnu-to-ppc64le-linux-gnu
 972 ```


1076 #### X11
1077 
1078 You will need X11 libraries suitable for your *target* system. For most cases,
1079 using Debian's pre-built libraries work fine.
1080 
1081 Note that X11 is needed even if you only want to build a headless JDK.
1082 
1083   * Go to [Debian Package Search](https://www.debian.org/distrib/packages),
1084     search for the following packages for your *target* system, and download them
1085     to /tmp/target-x11:
1086       * libxi
1087       * libxi-dev
1088       * x11proto-core-dev
1089       * x11proto-input-dev
1090       * x11proto-kb-dev
1091       * x11proto-render-dev
1092       * x11proto-xext-dev
1093       * libice-dev
1094       * libxrender
1095       * libxrender-dev
1096       * libxrandr-dev
1097       * libsm-dev
1098       * libxt-dev
1099       * libx11
1100       * libx11-dev
1101       * libxtst
1102       * libxtst-dev
1103       * libxext
1104       * libxext-dev
1105 
1106   * Install the libraries into the cross-compilation toolchain. For instance:
1107     ```
1108     cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc/usr
1109     mkdir X11R6
1110     cd X11R6
1111     for deb in /tmp/target-x11/*.deb ; do dpkg-deb -x $deb . ; done
1112     mv usr/* .
1113     cd lib
1114     cp arm-linux-gnueabihf/* .
1115     ```
1116 


1127 
1128 ### Creating And Using Sysroots With qemu-deboostrap
1129 
1130 Fortunately, you can create sysroots for foreign architectures with tools
1131 provided by your OS. On Debian/Ubuntu systems, one could use `qemu-deboostrap` to
1132 create the *target* system chroot, which would have the native libraries and headers
1133 specific to that *target* system. After that, we can use the cross-compiler on the *build*
1134 system, pointing into chroot to get the build dependencies right. This allows building
1135 for foreign architectures with native compilation speed.
1136 
1137 For example, cross-compiling to AArch64 from x86_64 could be done like this:
1138 
1139   * Install cross-compiler on the *build* system:
1140 ```
1141 apt install g++-aarch64-linux-gnu gcc-aarch64-linux-gnu
1142 ```
1143 
1144   * Create chroot on the *build* system, configuring it for *target* system:
1145 ```
1146 sudo qemu-debootstrap --arch=arm64 --verbose \
1147        --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 \
1148        --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
1149 ```
1150 
1151   * Configure and build with newly created chroot as sysroot/toolchain-path:
1152 ```
1153 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/
1154 make images
1155 ls build/linux-aarch64-normal-server-release/
1156 ```
1157 
1158 The build does not create new files in that chroot, so it can be reused for multiple builds
1159 without additional cleanup.
1160 
1161 Architectures that are known to successfully cross-compile like this are:
1162 
1163   Target        `CC`                      `CXX`                       `--arch=...`  `--openjdk-target=...`
1164   ------------  ------------------------- --------------------------- ------------- -----------------------
1165   x86           default                   default                     i386          i386-linux-gnu
1166   armhf         gcc-arm-linux-gnueabihf   g++-arm-linux-gnueabihf     armhf         arm-linux-gnueabihf
1167   aarch64       gcc-aarch64-linux-gnu     g++-aarch64-linux-gnu       arm64         aarch64-linux-gnu
1168   ppc64el       gcc-powerpc64le-linux-gnu g++-powerpc64le-linux-gnu   ppc64el       powerpc64le-linux-gnu
1169   s390x         gcc-s390x-linux-gnu       g++-s390x-linux-gnu         s390x         s390x-linux-gnu
1170 
1171 Additional architectures might be supported by Debian/Ubuntu Ports.
1172 
1173 ### Building for ARM/aarch64
1174 
1175 A common cross-compilation target is the ARM CPU. When building for ARM, it is
1176 useful to set the ABI profile. A number of pre-defined ABI profiles are
1177 available using `--with-abi-profile`: arm-vfp-sflt, arm-vfp-hflt, arm-sflt,
1178 armv5-vfp-sflt, armv6-vfp-hflt. Note that soft-float ABIs are no longer
1179 properly supported by the JDK.
1180 
1181 ### Verifying the Build
1182 
1183 The build will end up in a directory named like
1184 `build/linux-arm-normal-server-release`.
1185 
1186 Inside this build output directory, the `images/jdk` will contain the newly
1187 built JDK, for your *target* system.
1188 
1189 Copy these folders to your *target* system. Then you can run e.g.




  58 
  59 ### Special Considerations
  60 
  61 For a smooth building experience, it is recommended that you follow these rules
  62 on where and how to check out the source code.
  63 
  64   * Do not check out the source code in a path which contains spaces. Chances
  65     are the build will not work. This is most likely to be an issue on Windows
  66     systems.
  67 
  68   * Do not check out the source code in a path which has a very long name or is
  69     nested many levels deep. Chances are you will hit an OS limitation during
  70     the build.
  71 
  72   * Put the source code on a local disk, not a network share. If possible, use
  73     an SSD. The build process is very disk intensive, and having slow disk
  74     access will significantly increase build times. If you need to use a
  75     network share for the source code, see below for suggestions on how to keep
  76     the build artifacts on a local disk.
  77 
  78   * On Windows, extra care must be taken to make sure the [Cygwin](#cygwin)
  79     environment is consistent. It is recommended that you follow this
  80     procedure:
  81 
  82       * Create the directory that is going to contain the top directory of the
  83         JDK clone by using the `mkdir` command in the Cygwin bash shell.
  84         That is, do *not* create it using Windows Explorer. This will ensure
  85         that it will have proper Cygwin attributes, and that it's children will
  86         inherit those attributes.
  87 
  88       * Do not put the JDK clone in a path under your Cygwin home
  89         directory. This is especially important if your user name contains
  90         spaces and/or mixed upper and lower case letters.
  91 
  92       * Clone the JDK repository using the Cygwin command line `hg` client
  93         as instructed in this document. That is, do *not* use another Mercurial
  94         client such as TortoiseHg.
  95 
  96     Failure to follow this procedure might result in hard-to-debug build
  97     problems.
  98 
  99 ## Build Hardware Requirements


 133 
 134 This is not recommended. Instead, see the section on [Cross-compiling](
 135 #cross-compiling).
 136 
 137 ## Operating System Requirements
 138 
 139 The mainline JDK project supports Linux, Solaris, macOS, AIX and Windows.
 140 Support for other operating system, e.g. BSD, exists in separate "port"
 141 projects.
 142 
 143 In general, the JDK can be built on a wide range of versions of these operating
 144 systems, but the further you deviate from what is tested on a daily basis, the
 145 more likely you are to run into problems.
 146 
 147 This table lists the OS versions used by Oracle when building the JDK. Such
 148 information is always subject to change, but this table is up to date at the
 149 time of writing.
 150 
 151  Operating system   Vendor/version used
 152  -----------------  -------------------------------------------------------
 153  Linux              Oracle Enterprise Linux 6.4 / 7.1 (using kernel 3.8.13)
 154  Solaris            Solaris 11.1 SRU 21.4.1 / 11.2 SRU 5.5
 155  macOS              Mac OS X 10.9 (Mavericks) / 10.10 (Yosemite)
 156  Windows            Windows Server 2012 R2
 157 
 158 The double version numbers for Linux, Solaris and macOS is due to the hybrid
 159 model used at Oracle, where header files and external libraries from an older
 160 version are used when building on a more modern version of the OS.
 161 
 162 The Build Group has a wiki page with [Supported Build Platforms](
 163 https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From
 164 time to time, this is updated by contributors to list successes or failures of
 165 building on different platforms.
 166 
 167 ### Windows
 168 
 169 Windows XP is not a supported platform, but all newer Windows should be able to
 170 build the JDK.
 171 
 172 On Windows, it is important that you pay attention to the instructions in the
 173 [Special Considerations](#special-considerations).
 174 
 175 Windows is the only non-POSIX OS supported by the JDK, and as such, requires
 176 some extra care. A POSIX support layer is required to build on Windows.
 177 Currently, the only supported such layer is Cygwin. (Msys is no longer
 178 supported due to a too old bash; msys2 and the new Windows Subsystem for Linux
 179 (WSL) would likely be possible to support in a future version but that would
 180 require effort to implement.)
 181 
 182 Internally in the build system, all paths are represented as Unix-style paths,
 183 e.g. `/cygdrive/c/hg/jdk9/Makefile` rather than `C:\hg\jdk9\Makefile`. This
 184 rule also applies to input to the build system, e.g. in arguments to
 185 `configure`. So, use `--with-msvcr-dll=/cygdrive/c/msvcr100.dll` rather than
 186 `--with-msvcr-dll=c:\msvcr100.dll`. For details on this conversion, see the section
 187 on [Fixpath](#fixpath).
 188 
 189 #### Cygwin
 190 
 191 A functioning [Cygwin](http://www.cygwin.com/) environment is thus required for
 192 building the JDK on Windows. If you have a 64-bit OS, we strongly recommend
 193 using the 64-bit version of Cygwin.
 194 
 195 **Note:** Cygwin has a model of continuously updating all packages without any
 196 easy way to install or revert to a specific version of a package. This means
 197 that whenever you add or update a package in Cygwin, you might (inadvertently)
 198 update tools that are used by the JDK build process, and that can cause
 199 unexpected build problems.
 200 
 201 The JDK requires GNU Make 4.0 or greater on Windows. This is usually not a
 202 problem, since Cygwin currently only distributes GNU Make at a version above
 203 4.0.
 204 
 205 Apart from the basic Cygwin installation, the following packages must also be
 206 installed:
 207 
 208   * `autoconf`
 209   * `make`
 210   * `zip`
 211   * `unzip`
 212 
 213 Often, you can install these packages using the following command line:
 214 ```
 215 <path to Cygwin setup>/setup-x86_64 -q -P autoconf -P make -P unzip -P zip
 216 ```
 217 
 218 Unfortunately, Cygwin can be unreliable in certain circumstances. If you
 219 experience build tool crashes or strange issues when building on Windows,
 220 please check the Cygwin FAQ on the ["BLODA" list](
 221 https://cygwin.com/faq/faq.html#faq.using.bloda) and the section on [fork()
 222 failures](https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures).
 223 
























 224 ### Solaris
 225 
 226 See `make/devkit/solaris11.1-package-list.txt` for a list of recommended
 227 packages to install when building on Solaris. The versions specified in this
 228 list is the versions used by the daily builds at Oracle, and is likely to work
 229 properly.
 230 
 231 Older versions of Solaris shipped a broken version of `objcopy`. At least
 232 version 2.21.1 is needed, which is provided by Solaris 11 Update 1. Objcopy is
 233 needed if you want to have external debug symbols. Please make sure you are
 234 using at least version 2.21.1 of objcopy, or that you disable external debug
 235 symbols.
 236 
 237 ### macOS
 238 
 239 Apple is using a quite aggressive scheme of pushing OS updates, and coupling
 240 these updates with required updates of Xcode. Unfortunately, this makes it
 241 difficult for a project such as the JDK to keep pace with a continuously updated
 242 machine running macOS. See the section on [Apple Xcode](#apple-xcode) on some
 243 strategies to deal with this.


 254 
 255 It is often not much problem to build the JDK on Linux. The only general advice
 256 is to try to use the compilers, external libraries and header files as provided
 257 by your distribution.
 258 
 259 The basic tooling is provided as part of the core operating system, but you
 260 will most likely need to install developer packages.
 261 
 262 For apt-based distributions (Debian, Ubuntu, etc), try this:
 263 ```
 264 sudo apt-get install build-essential
 265 ```
 266 
 267 For rpm-based distributions (Fedora, Red Hat, etc), try this:
 268 ```
 269 sudo yum groupinstall "Development Tools"
 270 ```
 271 
 272 ### AIX
 273 
 274 The regular builds by SAP is using AIX version 7.1, but AIX 5.3 is also
 275 supported. See the [OpenJDK PowerPC Port Status Page](
 276 http://cr.openjdk.java.net/~simonis/ppc-aix-port) for details.
 277 
 278 ## Native Compiler (Toolchain) Requirements
 279 
 280 Large portions of the JDK consists of native code, that needs to be compiled to
 281 be able to run on the target platform. In theory, toolchain and operating
 282 system should be independent factors, but in practice there's more or less a
 283 one-to-one correlation between target operating system and toolchain.
 284 
 285  Operating system   Supported toolchain
 286  ------------------ -------------------------
 287  Linux              gcc, clang
 288  macOS              Apple Xcode (using clang)
 289  Solaris            Oracle Solaris Studio
 290  AIX                IBM XL C/C++
 291  Windows            Microsoft Visual Studio
 292 
 293 Please see the individual sections on the toolchains for version
 294 recommendations. As a reference, these versions of the toolchains are used, at
 295 the time of writing, by Oracle for the daily builds of the JDK. It should be
 296 possible to compile the JDK with both older and newer versions, but the closer
 297 you stay to this list, the more likely you are to compile successfully without
 298 issues.
 299 
 300  Operating system   Toolchain version
 301  ------------------ -------------------------------------------------------
 302  Linux              gcc 7.3.0
 303  macOS              Apple Xcode 9.4 (using clang 9.1.0)
 304  Solaris            Oracle Solaris Studio 12.4 (with compiler version 5.13)
 305  Windows            Microsoft Visual Studio 2017 update 15.5.5





 306 
 307 ### gcc
 308 
 309 The minimum accepted version of gcc is 4.8. Older versions will generate a warning
 310 by `configure` and are unlikely to work.
 311 
 312 The JDK is currently known to be able to compile with at least version 7.4 of
 313 gcc.
 314 
 315 In general, any version between these two should be usable.
 316 
 317 ### clang
 318 
 319 The minimum accepted version of clang is 3.2. Older versions will not be
 320 accepted by `configure`.
 321 
 322 To use clang instead of gcc on Linux, use `--with-toolchain-type=clang`.
 323 
 324 ### Apple Xcode
 325 


 363  developer/solarisstudio-124/library/math-libs      12.4-1.0.0.1
 364  developer/solarisstudio-124/library/studio-gccrt   12.4-1.0.0.1
 365  developer/solarisstudio-124/studio-common          12.4-1.0.0.1
 366  developer/solarisstudio-124/studio-ja              12.4-1.0.0.1
 367  developer/solarisstudio-124/studio-legal           12.4-1.0.0.1
 368  developer/solarisstudio-124/studio-zhCN            12.4-1.0.0.1
 369 
 370 Compiling with Solaris Studio can sometimes be finicky. This is the exact
 371 version used by Oracle, which worked correctly at the time of writing:
 372 ```
 373 $ cc -V
 374 cc: Sun C 5.13 SunOS_i386 2014/10/20
 375 $ CC -V
 376 CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30
 377 ```
 378 
 379 ### Microsoft Visual Studio
 380 
 381 The minimum accepted version of Visual Studio is 2010. Older versions will not
 382 be accepted by `configure`. The maximum accepted version of Visual Studio is
 383 2017. Versions older than 2017 are unlikely to continue working for long.
 384 
 385 If you have multiple versions of Visual Studio installed, `configure` will by
 386 default pick the latest. You can request a specific version to be used by
 387 setting `--with-toolchain-version`, e.g. `--with-toolchain-version=2015`.
 388 
 389 If you get `LINK: fatal error LNK1123: failure during conversion to COFF: file
 390 invalid` when building using Visual Studio 2010, you have encountered
 391 [KB2757355](http://support.microsoft.com/kb/2757355), a bug triggered by a
 392 specific installation order. However, the solution suggested by the KB article
 393 does not always resolve the problem. See [this stackoverflow discussion](
 394 https://stackoverflow.com/questions/10888391) for other suggestions.
 395 
 396 ### IBM XL C/C++
 397 
 398 The regular builds by SAP is using version 12.1, described as `IBM XL C/C++ for
 399 AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0017`.

 400 
 401 See the [OpenJDK PowerPC Port Status Page](
 402 http://cr.openjdk.java.net/~simonis/ppc-aix-port) for details.
 403 
 404 ## Boot JDK Requirements
 405 
 406 Paradoxically, building the JDK requires a pre-existing JDK. This is called the
 407 "boot JDK". The boot JDK does not, however, have to be a JDK built directly from
 408 the source code available in the OpenJDK Community.  If you are porting the JDK
 409 to a new platform, chances are that there already exists another JDK for that
 410 platform that is usable as boot JDK.
 411 
 412 The rule of thumb is that the boot JDK for building JDK major version *N*
 413 should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 would be
 414 suitable as boot JDK. However, the JDK should be able to "build itself", so an
 415 up-to-date build of the current JDK source is an acceptable alternative. If
 416 you are following the *N-1* rule, make sure you've got the latest update
 417 version, since JDK 8 GA might not be able to build JDK 9 on all platforms.
 418 
 419 Early in the release cycle, version *N-1* may not yet have been released. In
 420 that case, the preferred boot JDK will be version *N-2* until version *N-1*
 421 is available.
 422 


 471 
 472 CUPS, [Common UNIX Printing System](http://www.cups.org) header files are
 473 required on all platforms, except Windows. Often these files are provided by
 474 your operating system.
 475 
 476   * To install on an apt-based Linux, try running `sudo apt-get install
 477     libcups2-dev`.
 478   * To install on an rpm-based Linux, try running `sudo yum install
 479     cups-devel`.
 480   * To install on Solaris, try running `pkg install print/cups`.
 481 
 482 Use `--with-cups=<path>` if `configure` does not properly locate your CUPS
 483 files.
 484 
 485 ### X11
 486 
 487 Certain [X11](http://www.x.org/) libraries and include files are required on
 488 Linux and Solaris.
 489 
 490   * To install on an apt-based Linux, try running `sudo apt-get install
 491     libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
 492   * To install on an rpm-based Linux, try running `sudo yum install
 493     libXtst-devel libXt-devel libXrender-devel libXi-devel`.
 494   * To install on Solaris, try running `pkg install x11/header/x11-protocols
 495     x11/library/libice x11/library/libpthread-stubs x11/library/libsm
 496     x11/library/libx11 x11/library/libxau x11/library/libxcb
 497     x11/library/libxdmcp x11/library/libxevie x11/library/libxext
 498     x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
 499     x11/library/toolkit/libxt`.
 500 
 501 Use `--with-x=<path>` if `configure` does not properly locate your X11 files.
 502 
 503 ### ALSA
 504 
 505 ALSA, [Advanced Linux Sound Architecture](https://www.alsa-project.org/) is
 506 required on Linux. At least version 0.9.1 of ALSA is required.
 507 
 508   * To install on an apt-based Linux, try running `sudo apt-get install
 509     libasound2-dev`.
 510   * To install on an rpm-based Linux, try running `sudo yum install
 511     alsa-lib-devel`.
 512 
 513 Use `--with-alsa=<path>` if `configure` does not properly locate your ALSA
 514 files.
 515 
 516 ### libffi
 517 
 518 libffi, the [Portable Foreign Function Interface Library](
 519 http://sourceware.org/libffi) is required when building the Zero version of


 645   * `--with-version-string=<string>` - Specify the version string this build
 646     will be identified with.
 647   * `--with-version-<part>=<value>` - A group of options, where `<part>` can be
 648     any of `pre`, `opt`, `build`, `major`, `minor`, `security` or `patch`. Use
 649     these options to modify just the corresponding part of the version string
 650     from the default, or the value provided by `--with-version-string`.
 651   * `--with-jvm-variants=<variant>[,<variant>...]` - Build the specified variant
 652     (or variants) of Hotspot. Valid variants are: `server`, `client`,
 653     `minimal`, `core`, `zero`, `custom`. Note that not all
 654     variants are possible to combine in a single build.
 655   * `--with-jvm-features=<feature>[,<feature>...]` - Use the specified JVM
 656     features when building Hotspot. The list of features will be enabled on top
 657     of the default list. For the `custom` JVM variant, this default list is
 658     empty. A complete list of available JVM features can be found using `bash
 659     configure --help`.
 660   * `--with-target-bits=<bits>` - Create a target binary suitable for running
 661     on a `<bits>` platform. Use this to create 32-bit output on a 64-bit build
 662     platform, instead of doing a full cross-compile. (This is known as a
 663     *reduced* build.)
 664 








 665 #### Configure Arguments for Native Compilation
 666 
 667   * `--with-devkit=<path>` - Use this devkit for compilers, tools and resources
 668   * `--with-sysroot=<path>` - Use this directory as sysroot
 669   * `--with-extra-path=<path>[;<path>]` - Prepend these directories to the
 670     default path when searching for all kinds of binaries
 671   * `--with-toolchain-path=<path>[;<path>]` - Prepend these directories when
 672     searching for toolchain binaries (compilers etc)
 673   * `--with-extra-cflags=<flags>` - Append these flags when compiling JDK C
 674     files
 675   * `--with-extra-cxxflags=<flags>` - Append these flags when compiling JDK C++
 676     files
 677   * `--with-extra-ldflags=<flags>` - Append these flags when linking JDK
 678     libraries
 679 
 680 #### Configure Arguments for External Dependencies
 681 
 682   * `--with-boot-jdk=<path>` - Set the path to the [Boot JDK](
 683     #boot-jdk-requirements)
 684   * `--with-freetype=<path>` - Set the path to [FreeType](#freetype)
 685   * `--with-cups=<path>` - Set the path to [CUPS](#cups)
 686   * `--with-x=<path>` - Set the path to [X11](#x11)
 687   * `--with-alsa=<path>` - Set the path to [ALSA](#alsa)
 688   * `--with-libffi=<path>` - Set the path to [libffi](#libffi)
 689   * `--with-jtreg=<path>` - Set the path to JTReg. See [Running Tests](
 690     #running-tests)
 691 
 692 Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms
 693 and zlib) are included in the JDK repository. The default behavior of the
 694 JDK build is to use this version of these libraries, but they might be
 695 replaced by an external version. To do so, specify `system` as the `<source>`
 696 option in these arguments. (The default is `bundled`).



 697 
 698   * `--with-libjpeg=<source>` - Use the specified source for libjpeg
 699   * `--with-giflib=<source>` - Use the specified source for giflib
 700   * `--with-libpng=<source>` - Use the specified source for libpng
 701   * `--with-lcms=<source>` - Use the specified source for lcms
 702   * `--with-zlib=<source>` - Use the specified source for zlib
 703 
 704 On Linux, it is possible to select either static or dynamic linking of the C++
 705 runtime. The default is static linking, with dynamic linking as fallback if the
 706 static library is not found.
 707 
 708   * `--with-stdc++lib=<method>` - Use the specified method (`static`, `dynamic`
 709     or `default`) for linking the C++ runtime.
 710 
 711 ### Configure Control Variables
 712 
 713 It is possible to control certain aspects of `configure` by overriding the
 714 value of `configure` variables, either on the command line or in the
 715 environment.
 716 


 893 the following command:
 894 ```
 895 bash configure --with-devkit=<devkit-path> --openjdk-target=ppc64-linux-gnu && make
 896 ```
 897 
 898 will configure and build OpenJDK for Linux/ppc64 assuming that `<devkit-path>`
 899 points to a Linux/x86_64 to Linux/ppc64 devkit.
 900 
 901 Devkits can be created from the `make/devkit` directory by executing:
 902 ```
 903 make [ TARGETS="<TARGET_TRIPLET>+" ] [ BASE_OS=<OS> ] [ BASE_OS_VERSION=<VER> ]
 904 ```
 905 
 906 where `TARGETS` contains one or more `TARGET_TRIPLET`s of the form
 907 described in [section 3.4 of the GNU Autobook](
 908 https://sourceware.org/autobook/autobook/autobook_17.html). If no
 909 targets are given, a native toolchain for the current platform will be
 910 created. Currently, at least the following targets are known to work:
 911 
 912  Supported devkit targets
 913  ------------------------
 914  x86_64-linux-gnu
 915  aarch64-linux-gnu
 916  arm-linux-gnueabihf
 917  ppc64-linux-gnu
 918  ppc64le-linux-gnu
 919  s390x-linux-gnu
 920 
 921 `BASE_OS` must be one of "OEL6" for Oracle Enterprise Linux 6 or
 922 "Fedora" (if not specified "OEL6" will be the default). If the base OS
 923 is "Fedora" the corresponding Fedora release can be specified with the
 924 help of the `BASE_OS_VERSION` option (with "27" as default version).
 925 If the build is successful, the new devkits can be found in the
 926 `build/devkit/result` subdirectory:
 927 ```
 928 cd make/devkit
 929 make TARGETS="ppc64le-linux-gnu aarch64-linux-gnu" BASE_OS=Fedora BASE_OS_VERSION=21
 930 ls -1 ../../build/devkit/result/
 931 x86_64-linux-gnu-to-aarch64-linux-gnu
 932 x86_64-linux-gnu-to-ppc64le-linux-gnu
 933 ```


1037 #### X11
1038 
1039 You will need X11 libraries suitable for your *target* system. For most cases,
1040 using Debian's pre-built libraries work fine.
1041 
1042 Note that X11 is needed even if you only want to build a headless JDK.
1043 
1044   * Go to [Debian Package Search](https://www.debian.org/distrib/packages),
1045     search for the following packages for your *target* system, and download them
1046     to /tmp/target-x11:
1047       * libxi
1048       * libxi-dev
1049       * x11proto-core-dev
1050       * x11proto-input-dev
1051       * x11proto-kb-dev
1052       * x11proto-render-dev
1053       * x11proto-xext-dev
1054       * libice-dev
1055       * libxrender
1056       * libxrender-dev

1057       * libsm-dev
1058       * libxt-dev
1059       * libx11
1060       * libx11-dev
1061       * libxtst
1062       * libxtst-dev
1063       * libxext
1064       * libxext-dev
1065 
1066   * Install the libraries into the cross-compilation toolchain. For instance:
1067     ```
1068     cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc/usr
1069     mkdir X11R6
1070     cd X11R6
1071     for deb in /tmp/target-x11/*.deb ; do dpkg-deb -x $deb . ; done
1072     mv usr/* .
1073     cd lib
1074     cp arm-linux-gnueabihf/* .
1075     ```
1076 


1087 
1088 ### Creating And Using Sysroots With qemu-deboostrap
1089 
1090 Fortunately, you can create sysroots for foreign architectures with tools
1091 provided by your OS. On Debian/Ubuntu systems, one could use `qemu-deboostrap` to
1092 create the *target* system chroot, which would have the native libraries and headers
1093 specific to that *target* system. After that, we can use the cross-compiler on the *build*
1094 system, pointing into chroot to get the build dependencies right. This allows building
1095 for foreign architectures with native compilation speed.
1096 
1097 For example, cross-compiling to AArch64 from x86_64 could be done like this:
1098 
1099   * Install cross-compiler on the *build* system:
1100 ```
1101 apt install g++-aarch64-linux-gnu gcc-aarch64-linux-gnu
1102 ```
1103 
1104   * Create chroot on the *build* system, configuring it for *target* system:
1105 ```
1106 sudo qemu-debootstrap --arch=arm64 --verbose \
1107        --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev \
1108        --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
1109 ```
1110 
1111   * Configure and build with newly created chroot as sysroot/toolchain-path:
1112 ```
1113 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/
1114 make images
1115 ls build/linux-aarch64-normal-server-release/
1116 ```
1117 
1118 The build does not create new files in that chroot, so it can be reused for multiple builds
1119 without additional cleanup.
1120 
1121 Architectures that are known to successfully cross-compile like this are:
1122 
1123   Target        `CC`                      `CXX`                       `--arch=...` `--openjdk-target=...`
1124   ------------  ------------------------- --------------------------- ------------ ----------------------
1125   x86           default                   default                     i386         i386-linux-gnu
1126   armhf         gcc-arm-linux-gnueabihf   g++-arm-linux-gnueabihf     armhf        arm-linux-gnueabihf
1127   aarch64       gcc-aarch64-linux-gnu     g++-aarch64-linux-gnu       arm64        aarch64-linux-gnu
1128   ppc64el       gcc-powerpc64le-linux-gnu g++-powerpc64le-linux-gnu   ppc64el      powerpc64le-linux-gnu
1129   s390x         gcc-s390x-linux-gnu       g++-s390x-linux-gnu         s390x        s390x-linux-gnu
1130 
1131 Additional architectures might be supported by Debian/Ubuntu Ports.
1132 
1133 ### Building for ARM/aarch64
1134 
1135 A common cross-compilation target is the ARM CPU. When building for ARM, it is
1136 useful to set the ABI profile. A number of pre-defined ABI profiles are
1137 available using `--with-abi-profile`: arm-vfp-sflt, arm-vfp-hflt, arm-sflt,
1138 armv5-vfp-sflt, armv6-vfp-hflt. Note that soft-float ABIs are no longer
1139 properly supported by the JDK.
1140 
1141 ### Verifying the Build
1142 
1143 The build will end up in a directory named like
1144 `build/linux-arm-normal-server-release`.
1145 
1146 Inside this build output directory, the `images/jdk` will contain the newly
1147 built JDK, for your *target* system.
1148 
1149 Copy these folders to your *target* system. Then you can run e.g.


< prev index next >