author | eosterlund |
Mon, 04 Jun 2018 12:59:51 +0200 | |
changeset 50375 | bfbe7d8369bb |
parent 50267 | 1582de22e3a1 |
child 50490 | cbae0e359538 |
permissions | -rw-r--r-- |
45763 | 1 |
% Building OpenJDK |
2 |
||
3 |
## TL;DR (Instructions for the Impatient) |
|
4 |
||
5 |
If you are eager to try out building OpenJDK, these simple steps works most of |
|
6 |
the time. They assume that you have installed Mercurial (and Cygwin if running |
|
7 |
on Windows) and cloned the top-level OpenJDK repository that you want to build. |
|
8 |
||
9 |
1. [Get the complete source code](#getting-the-source-code): \ |
|
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
10 |
`hg clone http://hg.openjdk.java.net/jdk/jdk` |
45763 | 11 |
|
12 |
2. [Run configure](#running-configure): \ |
|
13 |
`bash configure` |
|
33030 | 14 |
|
45763 | 15 |
If `configure` fails due to missing dependencies (to either the |
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
16 |
[toolchain](#native-compiler-toolchain-requirements), [build tools]( |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
17 |
#build-tools-requirements), [external libraries]( |
45763 | 18 |
#external-library-requirements) or the [boot JDK](#boot-jdk-requirements)), |
19 |
most of the time it prints a suggestion on how to resolve the situation on |
|
20 |
your platform. Follow the instructions, and try running `bash configure` |
|
21 |
again. |
|
33030 | 22 |
|
45763 | 23 |
3. [Run make](#running-make): \ |
24 |
`make images` |
|
25 |
||
26 |
4. Verify your newly built JDK: \ |
|
27 |
`./build/*/images/jdk/bin/java -version` |
|
28 |
||
29 |
5. [Run basic tests](##running-tests): \ |
|
30 |
`make run-test-tier1` |
|
31 |
||
32 |
If any of these steps failed, or if you want to know more about build |
|
33 |
requirements or build functionality, please continue reading this document. |
|
44078
673240c54c2e
8176509: Use pandoc for converting build readme to html
ihse
parents:
41040
diff
changeset
|
34 |
|
33030 | 35 |
## Introduction |
36 |
||
45763 | 37 |
OpenJDK is a complex software project. Building it requires a certain amount of |
38 |
technical expertise, a fair number of dependencies on external software, and |
|
39 |
reasonably powerful hardware. |
|
33030 | 40 |
|
45763 | 41 |
If you just want to use OpenJDK and not build it yourself, this document is not |
42 |
for you. See for instance [OpenJDK installation]( |
|
43 |
http://openjdk.java.net/install) for some methods of installing a prebuilt |
|
33030 | 44 |
OpenJDK. |
45 |
||
45763 | 46 |
## Getting the Source Code |
47 |
||
47217 | 48 |
Make sure you are getting the correct version. As of JDK 10, the source is no |
49 |
longer split into separate repositories so you only need to clone one single |
|
50 |
repository. At the [OpenJDK Mercurial server](http://hg.openjdk.java.net/) you |
|
51 |
can see a list of all available forests. If you want to build an older version, |
|
52 |
e.g. JDK 8, it is recommended that you get the `jdk8u` forest, which contains |
|
53 |
incremental updates, instead of the `jdk8` forest, which was frozen at JDK 8 GA. |
|
45763 | 54 |
|
55 |
If you are new to Mercurial, a good place to start is the [Mercurial Beginner's |
|
56 |
Guide](http://www.mercurial-scm.org/guide). The rest of this document assumes a |
|
57 |
working knowledge of Mercurial. |
|
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 |
OpenJDK 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 OpenJDK 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 OpenJDK 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 |
|
100 |
||
101 |
OpenJDK is a massive project, and require machines ranging from decent to |
|
102 |
powerful to be able to build in a reasonable amount of time, or to be able to |
|
103 |
complete a build at all. |
|
104 |
||
105 |
We *strongly* recommend usage of an SSD disk for the build, since disk speed is |
|
106 |
one of the limiting factors for build performance. |
|
107 |
||
108 |
### Building on x86 |
|
109 |
||
110 |
At a minimum, a machine with 2-4 cores is advisable, as well as 2-4 GB of RAM. |
|
111 |
(The more cores to use, the more memory you need.) At least 6 GB of free disk |
|
112 |
space is required (8 GB minimum for building on Solaris). |
|
113 |
||
114 |
Even for 32-bit builds, it is recommended to use a 64-bit build machine, and |
|
115 |
instead create a 32-bit target using `--with-target-bits=32`. |
|
116 |
||
117 |
### Building on sparc |
|
118 |
||
119 |
At a minimum, a machine with 4 cores is advisable, as well as 4 GB of RAM. (The |
|
120 |
more cores to use, the more memory you need.) At least 8 GB of free disk space |
|
121 |
is required. |
|
122 |
||
123 |
### Building on arm/aarch64 |
|
124 |
||
125 |
This is not recommended. Instead, see the section on [Cross-compiling]( |
|
126 |
#cross-compiling). |
|
127 |
||
128 |
## Operating System Requirements |
|
129 |
||
130 |
The mainline OpenJDK project supports Linux, Solaris, macOS, AIX and Windows. |
|
131 |
Support for other operating system, e.g. BSD, exists in separate "port" |
|
132 |
projects. |
|
133 |
||
134 |
In general, OpenJDK can be built on a wide range of versions of these operating |
|
135 |
systems, but the further you deviate from what is tested on a daily basis, the |
|
136 |
more likely you are to run into problems. |
|
137 |
||
138 |
This table lists the OS versions used by Oracle when building JDK 9. Such |
|
139 |
information is always subject to change, but this table is up to date at the |
|
140 |
time of writing. |
|
141 |
||
142 |
Operating system Vendor/version used |
|
143 |
----------------- ------------------------------------------------------- |
|
144 |
Linux Oracle Enterprise Linux 6.4 / 7.1 (using kernel 3.8.13) |
|
145 |
Solaris Solaris 11.1 SRU 21.4.1 / 11.2 SRU 5.5 |
|
146 |
macOS Mac OS X 10.9 (Mavericks) / 10.10 (Yosemite) |
|
147 |
Windows Windows Server 2012 R2 |
|
33030 | 148 |
|
45763 | 149 |
The double version numbers for Linux, Solaris and macOS is due to the hybrid |
150 |
model used at Oracle, where header files and external libraries from an older |
|
151 |
version is used when building on a more modern version of the OS. |
|
152 |
||
153 |
The Build Group has a wiki page with [Supported Build Platforms]( |
|
154 |
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From |
|
155 |
time to time, this is updated by the community to list successes or failures of |
|
156 |
building on different platforms. |
|
157 |
||
158 |
### Windows |
|
159 |
||
160 |
Windows XP is not a supported platform, but all newer Windows should be able to |
|
161 |
build OpenJDK. |
|
162 |
||
163 |
On Windows, it is important that you pay attention to the instructions in the |
|
164 |
[Special Considerations](#special-considerations). |
|
165 |
||
166 |
Windows is the only non-POSIX OS supported by OpenJDK, and as such, requires |
|
167 |
some extra care. A POSIX support layer is required to build on Windows. For |
|
168 |
OpenJDK 9, the only supported such layer is Cygwin. (Msys is no longer |
|
169 |
supported due to a too old bash; msys2 and the new Windows Subsystem for Linux |
|
170 |
(WSL) would likely be possible to support in a future version but that would |
|
171 |
require a community effort to implement.) |
|
172 |
||
173 |
Internally in the build system, all paths are represented as Unix-style paths, |
|
174 |
e.g. `/cygdrive/c/hg/jdk9/Makefile` rather than `C:\hg\jdk9\Makefile`. This |
|
175 |
rule also applies to input to the build system, e.g. in arguments to |
|
49234
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
176 |
`configure`. So, use `--with-msvcr-dll=/cygdrive/c/msvcr100.dll` rather than |
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
177 |
`--with-msvcr-dll=c:\msvcr100.dll`. For details on this conversion, see the section |
45763 | 178 |
on [Fixpath](#fixpath). |
179 |
||
180 |
#### Cygwin |
|
181 |
||
182 |
A functioning [Cygwin](http://www.cygwin.com/) environment is thus required for |
|
183 |
building OpenJDK on Windows. If you have a 64-bit OS, we strongly recommend |
|
184 |
using the 64-bit version of Cygwin. |
|
185 |
||
186 |
**Note:** Cygwin has a model of continuously updating all packages without any |
|
187 |
easy way to install or revert to a specific version of a package. This means |
|
188 |
that whenever you add or update a package in Cygwin, you might (inadvertently) |
|
189 |
update tools that are used by the OpenJDK build process, and that can cause |
|
190 |
unexpected build problems. |
|
191 |
||
192 |
OpenJDK requires GNU Make 4.0 or greater on Windows. This is usually not a |
|
193 |
problem, since Cygwin currently only distributes GNU Make at a version above |
|
194 |
4.0. |
|
195 |
||
196 |
Apart from the basic Cygwin installation, the following packages must also be |
|
197 |
installed: |
|
198 |
||
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
199 |
* `autoconf` |
45763 | 200 |
* `make` |
201 |
* `zip` |
|
202 |
* `unzip` |
|
203 |
||
204 |
Often, you can install these packages using the following command line: |
|
205 |
``` |
|
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
206 |
<path to Cygwin setup>/setup-x86_64 -q -P autoconf -P make -P unzip -P zip |
45763 | 207 |
``` |
208 |
||
209 |
Unfortunately, Cygwin can be unreliable in certain circumstances. If you |
|
210 |
experience build tool crashes or strange issues when building on Windows, |
|
211 |
please check the Cygwin FAQ on the ["BLODA" list]( |
|
212 |
https://cygwin.com/faq/faq.html#faq.using.bloda) and the section on [fork() |
|
213 |
failures](https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures). |
|
214 |
||
215 |
### Solaris |
|
216 |
||
217 |
See `make/devkit/solaris11.1-package-list.txt` for a list of recommended |
|
218 |
packages to install when building on Solaris. The versions specified in this |
|
219 |
list is the versions used by the daily builds at Oracle, and is likely to work |
|
220 |
properly. |
|
221 |
||
222 |
Older versions of Solaris shipped a broken version of `objcopy`. At least |
|
223 |
version 2.21.1 is needed, which is provided by Solaris 11 Update 1. Objcopy is |
|
224 |
needed if you want to have external debug symbols. Please make sure you are |
|
225 |
using at least version 2.21.1 of objcopy, or that you disable external debug |
|
226 |
symbols. |
|
227 |
||
228 |
### macOS |
|
229 |
||
230 |
Apple is using a quite aggressive scheme of pushing OS updates, and coupling |
|
231 |
these updates with required updates of Xcode. Unfortunately, this makes it |
|
232 |
difficult for a project like OpenJDK to keep pace with a continuously updated |
|
233 |
machine running macOS. See the section on [Apple Xcode](#apple-xcode) on some |
|
234 |
strategies to deal with this. |
|
235 |
||
236 |
It is recommended that you use at least Mac OS X 10.9 (Mavericks). At the time |
|
237 |
of writing, OpenJDK has been successfully compiled on macOS versions up to |
|
238 |
10.12.5 (Sierra), using XCode 8.3.2 and `--disable-warnings-as-errors`. |
|
239 |
||
240 |
The standard macOS environment contains the basic tooling needed to build, but |
|
241 |
for external libraries a package manager is recommended. OpenJDK uses |
|
242 |
[homebrew](https://brew.sh/) in the examples, but feel free to use whatever |
|
243 |
manager you want (or none). |
|
244 |
||
245 |
### Linux |
|
246 |
||
247 |
It is often not much problem to build OpenJDK on Linux. The only general advice |
|
248 |
is to try to use the compilers, external libraries and header files as provided |
|
249 |
by your distribution. |
|
250 |
||
251 |
The basic tooling is provided as part of the core operating system, but you |
|
252 |
will most likely need to install developer packages. |
|
253 |
||
254 |
For apt-based distributions (Debian, Ubuntu, etc), try this: |
|
255 |
``` |
|
256 |
sudo apt-get install build-essential |
|
257 |
``` |
|
258 |
||
259 |
For rpm-based distributions (Fedora, Red Hat, etc), try this: |
|
260 |
``` |
|
261 |
sudo yum groupinstall "Development Tools" |
|
262 |
``` |
|
263 |
||
264 |
### AIX |
|
265 |
||
266 |
The regular builds by SAP is using AIX version 7.1, but AIX 5.3 is also |
|
267 |
supported. See the [OpenJDK PowerPC Port Status Page]( |
|
268 |
http://cr.openjdk.java.net/~simonis/ppc-aix-port) for details. |
|
269 |
||
270 |
## Native Compiler (Toolchain) Requirements |
|
271 |
||
272 |
Large portions of OpenJDK consists of native code, that needs to be compiled to |
|
273 |
be able to run on the target platform. In theory, toolchain and operating |
|
274 |
system should be independent factors, but in practice there's more or less a |
|
275 |
one-to-one correlation between target operating system and toolchain. |
|
276 |
||
277 |
Operating system Supported toolchain |
|
278 |
------------------ ------------------------- |
|
279 |
Linux gcc, clang |
|
280 |
macOS Apple Xcode (using clang) |
|
281 |
Solaris Oracle Solaris Studio |
|
282 |
AIX IBM XL C/C++ |
|
283 |
Windows Microsoft Visual Studio |
|
284 |
||
285 |
Please see the individual sections on the toolchains for version |
|
286 |
recommendations. As a reference, these versions of the toolchains are used, at |
|
287 |
the time of writing, by Oracle for the daily builds of OpenJDK. It should be |
|
288 |
possible to compile OpenJDK with both older and newer versions, but the closer |
|
289 |
you stay to this list, the more likely you are to compile successfully without |
|
290 |
issues. |
|
291 |
||
292 |
Operating system Toolchain version |
|
293 |
------------------ ------------------------------------------------------- |
|
294 |
Linux gcc 4.9.2 |
|
295 |
macOS Apple Xcode 6.3 (using clang 6.1.0) |
|
296 |
Solaris Oracle Solaris Studio 12.4 (with compiler version 5.13) |
|
297 |
Windows Microsoft Visual Studio 2013 update 4 |
|
298 |
||
299 |
### gcc |
|
300 |
||
47219 | 301 |
The minimum accepted version of gcc is 4.7. Older versions will generate a warning |
45877
640f1904ebb8
8184338: switch minimum supported gcc version to 4.7
mbaesken
parents:
45763
diff
changeset
|
302 |
by `configure` and are unlikely to work. |
45763 | 303 |
|
304 |
OpenJDK 9 includes patches that should allow gcc 6 to compile, but this should |
|
305 |
be considered experimental. |
|
306 |
||
307 |
In general, any version between these two should be usable. |
|
308 |
||
309 |
### clang |
|
310 |
||
311 |
The minimum accepted version of clang is 3.2. Older versions will not be |
|
312 |
accepted by `configure`. |
|
313 |
||
314 |
To use clang instead of gcc on Linux, use `--with-toolchain-type=clang`. |
|
315 |
||
316 |
### Apple Xcode |
|
317 |
||
318 |
The oldest supported version of Xcode is 5. |
|
319 |
||
320 |
You will need the Xcode command lines developers tools to be able to build |
|
321 |
OpenJDK. (Actually, *only* the command lines tools are needed, not the IDE.) |
|
322 |
The simplest way to install these is to run: |
|
323 |
``` |
|
324 |
xcode-select --install |
|
325 |
``` |
|
326 |
||
327 |
It is advisable to keep an older version of Xcode for building OpenJDK when |
|
328 |
updating Xcode. This [blog page]( |
|
329 |
http://iosdevelopertips.com/xcode/install-multiple-versions-of-xcode.html) has |
|
330 |
good suggestions on managing multiple Xcode versions. To use a specific version |
|
331 |
of Xcode, use `xcode-select -s` before running `configure`, or use |
|
332 |
`--with-toolchain-path` to point to the version of Xcode to use, e.g. |
|
333 |
`configure --with-toolchain-path=/Applications/Xcode5.app/Contents/Developer/usr/bin` |
|
334 |
||
335 |
If you have recently (inadvertently) updated your OS and/or Xcode version, and |
|
336 |
OpenJDK can no longer be built, please see the section on [Problems with the |
|
337 |
Build Environment](#problems-with-the-build-environment), and [Getting |
|
338 |
Help](#getting-help) to find out if there are any recent, non-merged patches |
|
339 |
available for this update. |
|
340 |
||
341 |
### Oracle Solaris Studio |
|
342 |
||
343 |
The minimum accepted version of the Solaris Studio compilers is 5.13 |
|
344 |
(corresponding to Solaris Studio 12.4). Older versions will not be accepted by |
|
345 |
configure. |
|
33030 | 346 |
|
34595
09596fe63e2d
8145391: Updated jprt.properties, devtools, jib and readme with SS12u4
erikj
parents:
33030
diff
changeset
|
347 |
The Solaris Studio installation should contain at least these packages: |
33030 | 348 |
|
45763 | 349 |
Package Version |
350 |
-------------------------------------------------- ------------- |
|
351 |
developer/solarisstudio-124/backend 12.4-1.0.6.0 |
|
352 |
developer/solarisstudio-124/c++ 12.4-1.0.10.0 |
|
353 |
developer/solarisstudio-124/cc 12.4-1.0.4.0 |
|
354 |
developer/solarisstudio-124/library/c++-libs 12.4-1.0.10.0 |
|
355 |
developer/solarisstudio-124/library/math-libs 12.4-1.0.0.1 |
|
356 |
developer/solarisstudio-124/library/studio-gccrt 12.4-1.0.0.1 |
|
357 |
developer/solarisstudio-124/studio-common 12.4-1.0.0.1 |
|
358 |
developer/solarisstudio-124/studio-ja 12.4-1.0.0.1 |
|
359 |
developer/solarisstudio-124/studio-legal 12.4-1.0.0.1 |
|
360 |
developer/solarisstudio-124/studio-zhCN 12.4-1.0.0.1 |
|
361 |
||
362 |
Compiling with Solaris Studio can sometimes be finicky. This is the exact |
|
363 |
version used by Oracle, which worked correctly at the time of writing: |
|
364 |
``` |
|
365 |
$ cc -V |
|
366 |
cc: Sun C 5.13 SunOS_i386 2014/10/20 |
|
367 |
$ CC -V |
|
368 |
CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30 |
|
369 |
``` |
|
370 |
||
371 |
### Microsoft Visual Studio |
|
372 |
||
373 |
The minimum accepted version of Visual Studio is 2010. Older versions will not |
|
374 |
be accepted by `configure`. The maximum accepted version of Visual Studio is |
|
375 |
2013. |
|
376 |
||
377 |
If you have multiple versions of Visual Studio installed, `configure` will by |
|
378 |
default pick the latest. You can request a specific version to be used by |
|
379 |
setting `--with-toolchain-version`, e.g. `--with-toolchain-version=2010`. |
|
33030 | 380 |
|
45763 | 381 |
If you get `LINK: fatal error LNK1123: failure during conversion to COFF: file |
382 |
invalid` when building using Visual Studio 2010, you have encountered |
|
383 |
[KB2757355](http://support.microsoft.com/kb/2757355), a bug triggered by a |
|
384 |
specific installation order. However, the solution suggested by the KB article |
|
385 |
does not always resolve the problem. See [this stackoverflow discussion]( |
|
386 |
https://stackoverflow.com/questions/10888391) for other suggestions. |
|
33030 | 387 |
|
45763 | 388 |
### IBM XL C/C++ |
389 |
||
390 |
The regular builds by SAP is using version 12.1, described as `IBM XL C/C++ for |
|
391 |
AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0017`. |
|
392 |
||
393 |
See the [OpenJDK PowerPC Port Status Page]( |
|
394 |
http://cr.openjdk.java.net/~simonis/ppc-aix-port) for details. |
|
395 |
||
396 |
## Boot JDK Requirements |
|
33030 | 397 |
|
45763 | 398 |
Paradoxically, building OpenJDK requires a pre-existing JDK. This is called the |
399 |
"boot JDK". The boot JDK does not have to be OpenJDK, though. If you are |
|
400 |
porting OpenJDK to a new platform, chances are that there already exists |
|
401 |
another JDK for that platform that is usable as boot JDK. |
|
33030 | 402 |
|
45763 | 403 |
The rule of thumb is that the boot JDK for building JDK major version *N* |
49159
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
404 |
should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 would be |
45763 | 405 |
suitable as boot JDK. However, OpenJDK should be able to "build itself", so an |
406 |
up-to-date build of the current OpenJDK source is an acceptable alternative. If |
|
49159
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
407 |
you are following the *N-1* rule, make sure you've got the latest update |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
408 |
version, since JDK 8 GA might not be able to build JDK 9 on all platforms. |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
409 |
|
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
410 |
Early in the release cycle, version *N-1* may not yet have been released. In |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
411 |
that case, the preferred boot JDK will be version *N-2* until version *N-1* |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
412 |
is available. |
33030 | 413 |
|
45763 | 414 |
If the Boot JDK is not automatically detected, or the wrong JDK is picked, use |
415 |
`--with-boot-jdk` to point to the JDK to use. |
|
416 |
||
49159
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
417 |
### Getting JDK binaries |
45763 | 418 |
|
49159
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
419 |
OpenJDK binaries for Linux, Windows and macOS can be downloaded from |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
420 |
[jdk.java.net](http://jdk.java.net). An alternative is to download the |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
421 |
[Oracle JDK](http://www.oracle.com/technetwork/java/javase/downloads). Another |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
422 |
is the [Adopt OpenJDK Project](https://adoptopenjdk.net/), which publishes |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
423 |
experimental prebuilt binaries for various platforms. |
45763 | 424 |
|
49159
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
425 |
On Linux you can also get OpenJDK from the Linux distribution. On apt-based |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
426 |
distros (like Debian and Ubuntu), `sudo apt-get install openjdk-<VERSION>-jdk` |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
427 |
is typically enough to install OpenJDK \<VERSION\>. On rpm-based distros (like |
436f1e03fd04
8199266: Update boot and build jdk requirements in configure
erikj
parents:
48743
diff
changeset
|
428 |
Fedora and Red Hat), try `sudo yum install java-<VERSION>-openjdk-devel`. |
45763 | 429 |
|
430 |
## External Library Requirements |
|
431 |
||
432 |
Different platforms require different external libraries. In general, libraries |
|
433 |
are not optional - that is, they are either required or not used. |
|
434 |
||
435 |
If a required library is not detected by `configure`, you need to provide the |
|
436 |
path to it. There are two forms of the `configure` arguments to point to an |
|
437 |
external library: `--with-<LIB>=<path>` or `--with-<LIB>-include=<path to |
|
438 |
include> --with-<LIB>-lib=<path to lib>`. The first variant is more concise, |
|
439 |
but require the include files an library files to reside in a default hierarchy |
|
440 |
under this directory. In most cases, it works fine. |
|
33030 | 441 |
|
45763 | 442 |
As a fallback, the second version allows you to point to the include directory |
443 |
and the lib directory separately. |
|
444 |
||
445 |
### FreeType |
|
446 |
||
49234
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
447 |
FreeType2 from [The FreeType Project](http://www.freetype.org/) is not required |
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
448 |
on any platform. The exception is on Unix-based platforms when configuring such |
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
449 |
that the build artifacts will reference a system installed library, |
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
450 |
rather than bundling OpenJDK's own copy. |
33030 | 451 |
|
45763 | 452 |
* To install on an apt-based Linux, try running `sudo apt-get install |
49234
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
453 |
libfreetype6-dev`. |
45763 | 454 |
* To install on an rpm-based Linux, try running `sudo yum install |
49234
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
455 |
freetype-devel`. |
45763 | 456 |
* To install on Solaris, try running `pkg install system/library/freetype-2`. |
33030 | 457 |
|
49234
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
458 |
Use `--with-freetype-include=<path>` and `--with-freetype-lib=<path>` |
3375a8039fde
8193017: Import freetype sources into OpenJDK source tree
prr
parents:
49159
diff
changeset
|
459 |
if `configure` does not automatically locate the platform FreeType files. |
45763 | 460 |
|
461 |
### CUPS |
|
462 |
||
463 |
CUPS, [Common UNIX Printing System](http://www.cups.org) header files are |
|
464 |
required on all platforms, except Windows. Often these files are provided by |
|
465 |
your operating system. |
|
33030 | 466 |
|
45763 | 467 |
* To install on an apt-based Linux, try running `sudo apt-get install |
468 |
libcups2-dev`. |
|
469 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
470 |
cups-devel`. |
|
471 |
* To install on Solaris, try running `pkg install print/cups`. |
|
33030 | 472 |
|
45763 | 473 |
Use `--with-cups=<path>` if `configure` does not properly locate your CUPS |
474 |
files. |
|
475 |
||
476 |
### X11 |
|
477 |
||
478 |
Certain [X11](http://www.x.org/) libraries and include files are required on |
|
479 |
Linux and Solaris. |
|
33030 | 480 |
|
45763 | 481 |
* To install on an apt-based Linux, try running `sudo apt-get install |
482 |
libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`. |
|
483 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
484 |
libXtst-devel libXt-devel libXrender-devel libXi-devel`. |
|
485 |
* To install on Solaris, try running `pkg install x11/header/x11-protocols |
|
486 |
x11/library/libice x11/library/libpthread-stubs x11/library/libsm |
|
487 |
x11/library/libx11 x11/library/libxau x11/library/libxcb |
|
488 |
x11/library/libxdmcp x11/library/libxevie x11/library/libxext |
|
489 |
x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst |
|
490 |
x11/library/toolkit/libxt`. |
|
491 |
||
492 |
Use `--with-x=<path>` if `configure` does not properly locate your X11 files. |
|
493 |
||
494 |
### ALSA |
|
495 |
||
496 |
ALSA, [Advanced Linux Sound Architecture](https://www.alsa-project.org/) is |
|
497 |
required on Linux. At least version 0.9.1 of ALSA is required. |
|
33030 | 498 |
|
45763 | 499 |
* To install on an apt-based Linux, try running `sudo apt-get install |
500 |
libasound2-dev`. |
|
501 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
502 |
alsa-lib-devel`. |
|
503 |
||
504 |
Use `--with-alsa=<path>` if `configure` does not properly locate your ALSA |
|
505 |
files. |
|
506 |
||
507 |
### libffi |
|
508 |
||
509 |
libffi, the [Portable Foreign Function Interface Library]( |
|
510 |
http://sourceware.org/libffi) is required when building the Zero version of |
|
511 |
Hotspot. |
|
512 |
||
513 |
* To install on an apt-based Linux, try running `sudo apt-get install |
|
514 |
libffi-dev`. |
|
515 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
516 |
libffi-devel`. |
|
517 |
||
518 |
Use `--with-libffi=<path>` if `configure` does not properly locate your libffi |
|
519 |
files. |
|
520 |
||
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
521 |
## Build Tools Requirements |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
522 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
523 |
### Autoconf |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
524 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
525 |
OpenJDK requires [Autoconf](http://www.gnu.org/software/autoconf) on all |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
526 |
platforms. At least version 2.69 is required. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
527 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
528 |
* To install on an apt-based Linux, try running `sudo apt-get install |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
529 |
autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
530 |
* To install on an rpm-based Linux, try running `sudo yum install |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
531 |
autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
532 |
* To install on macOS, try running `brew install autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
533 |
* To install on Windows, try running `<path to Cygwin setup>/setup-x86_64 -q |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
534 |
-P autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
535 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
536 |
If `configure` has problems locating your installation of autoconf, you can |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
537 |
specify it using the `AUTOCONF` environment variable, like this: |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
538 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
539 |
``` |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
540 |
AUTOCONF=<path to autoconf> configure ... |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
541 |
``` |
33030 | 542 |
|
45763 | 543 |
### GNU Make |
544 |
||
545 |
OpenJDK requires [GNU Make](http://www.gnu.org/software/make). No other flavors |
|
546 |
of make are supported. |
|
33030 | 547 |
|
45763 | 548 |
At least version 3.81 of GNU Make must be used. For distributions supporting |
549 |
GNU Make 4.0 or above, we strongly recommend it. GNU Make 4.0 contains useful |
|
550 |
functionality to handle parallel building (supported by `--with-output-sync`) |
|
551 |
and speed and stability improvements. |
|
33030 | 552 |
|
45763 | 553 |
Note that `configure` locates and verifies a properly functioning version of |
554 |
`make` and stores the path to this `make` binary in the configuration. If you |
|
555 |
start a build using `make` on the command line, you will be using the version |
|
556 |
of make found first in your `PATH`, and not necessarily the one stored in the |
|
557 |
configuration. This initial make will be used as "bootstrap make", and in a |
|
558 |
second stage, the make located by `configure` will be called. Normally, this |
|
559 |
will present no issues, but if you have a very old `make`, or a non-GNU Make |
|
560 |
`make` in your path, this might cause issues. |
|
561 |
||
562 |
If you want to override the default make found by `configure`, use the `MAKE` |
|
563 |
configure variable, e.g. `configure MAKE=/opt/gnu/make`. |
|
564 |
||
565 |
On Solaris, it is common to call the GNU version of make by using `gmake`. |
|
566 |
||
567 |
### GNU Bash |
|
33030 | 568 |
|
45763 | 569 |
OpenJDK requires [GNU Bash](http://www.gnu.org/software/bash). No other shells |
570 |
are supported. |
|
571 |
||
572 |
At least version 3.2 of GNU Bash must be used. |
|
573 |
||
574 |
## Running Configure |
|
33030 | 575 |
|
45763 | 576 |
To build OpenJDK, you need a "configuration", which consists of a directory |
577 |
where to store the build output, coupled with information about the platform, |
|
578 |
the specific build machine, and choices that affect how OpenJDK is built. |
|
33030 | 579 |
|
45763 | 580 |
The configuration is created by the `configure` script. The basic invocation of |
581 |
the `configure` script looks like this: |
|
33030 | 582 |
|
45763 | 583 |
``` |
584 |
bash configure [options] |
|
585 |
``` |
|
33030 | 586 |
|
45763 | 587 |
This will create an output directory containing the configuration and setup an |
588 |
area for the build result. This directory typically looks like |
|
589 |
`build/linux-x64-normal-server-release`, but the actual name depends on your |
|
590 |
specific configuration. (It can also be set directly, see [Using Multiple |
|
591 |
Configurations](#using-multiple-configurations)). This directory is referred to |
|
592 |
as `$BUILD` in this documentation. |
|
33030 | 593 |
|
594 |
`configure` will try to figure out what system you are running on and where all |
|
595 |
necessary build components are. If you have all prerequisites for building |
|
596 |
installed, it should find everything. If it fails to detect any component |
|
45763 | 597 |
automatically, it will exit and inform you about the problem. |
33030 | 598 |
|
45763 | 599 |
Some command line examples: |
33030 | 600 |
|
45763 | 601 |
* Create a 32-bit build for Windows with FreeType2 in `C:\freetype-i586`: |
602 |
``` |
|
603 |
bash configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32 |
|
604 |
``` |
|
33030 | 605 |
|
45763 | 606 |
* Create a debug build with the `server` JVM and DTrace enabled: |
607 |
``` |
|
608 |
bash configure --enable-debug --with-jvm-variants=server --enable-dtrace |
|
609 |
``` |
|
33030 | 610 |
|
45763 | 611 |
### Common Configure Arguments |
33030 | 612 |
|
45763 | 613 |
Here follows some of the most common and important `configure` argument. |
33030 | 614 |
|
45763 | 615 |
To get up-to-date information on *all* available `configure` argument, please |
616 |
run: |
|
617 |
``` |
|
618 |
bash configure --help |
|
619 |
``` |
|
33030 | 620 |
|
45763 | 621 |
(Note that this help text also include general autoconf options, like |
622 |
`--dvidir`, that is not relevant to OpenJDK. To list only OpenJDK specific |
|
623 |
features, use `bash configure --help=short` instead.) |
|
624 |
||
625 |
#### Configure Arguments for Tailoring the Build |
|
33030 | 626 |
|
45763 | 627 |
* `--enable-debug` - Set the debug level to `fastdebug` (this is a shorthand |
628 |
for `--with-debug-level=fastdebug`) |
|
629 |
* `--with-debug-level=<level>` - Set the debug level, which can be `release`, |
|
630 |
`fastdebug`, `slowdebug` or `optimized`. Default is `release`. `optimized` |
|
631 |
is variant of `release` with additional Hotspot debug code. |
|
632 |
* `--with-native-debug-symbols=<method>` - Specify if and how native debug |
|
633 |
symbols should be built. Available methods are `none`, `internal`, |
|
634 |
`external`, `zipped`. Default behavior depends on platform. See [Native |
|
635 |
Debug Symbols](#native-debug-symbols) for more details. |
|
636 |
* `--with-version-string=<string>` - Specify the version string this build |
|
637 |
will be identified with. |
|
638 |
* `--with-version-<part>=<value>` - A group of options, where `<part>` can be |
|
639 |
any of `pre`, `opt`, `build`, `major`, `minor`, `security` or `patch`. Use |
|
640 |
these options to modify just the corresponding part of the version string |
|
641 |
from the default, or the value provided by `--with-version-string`. |
|
642 |
* `--with-jvm-variants=<variant>[,<variant>...]` - Build the specified variant |
|
643 |
(or variants) of Hotspot. Valid variants are: `server`, `client`, |
|
47687 | 644 |
`minimal`, `core`, `zero`, `custom`. Note that not all |
45763 | 645 |
variants are possible to combine in a single build. |
646 |
* `--with-jvm-features=<feature>[,<feature>...]` - Use the specified JVM |
|
647 |
features when building Hotspot. The list of features will be enabled on top |
|
648 |
of the default list. For the `custom` JVM variant, this default list is |
|
649 |
empty. A complete list of available JVM features can be found using `bash |
|
650 |
configure --help`. |
|
651 |
* `--with-target-bits=<bits>` - Create a target binary suitable for running |
|
652 |
on a `<bits>` platform. Use this to create 32-bit output on a 64-bit build |
|
653 |
platform, instead of doing a full cross-compile. (This is known as a |
|
654 |
*reduced* build.) |
|
33030 | 655 |
|
45763 | 656 |
#### Configure Arguments for Native Compilation |
33030 | 657 |
|
45763 | 658 |
* `--with-devkit=<path>` - Use this devkit for compilers, tools and resources |
659 |
* `--with-sysroot=<path>` - Use this directory as sysroot |
|
660 |
* `--with-extra-path=<path>[;<path>]` - Prepend these directories to the |
|
661 |
default path when searching for all kinds of binaries |
|
662 |
* `--with-toolchain-path=<path>[;<path>]` - Prepend these directories when |
|
663 |
searching for toolchain binaries (compilers etc) |
|
664 |
* `--with-extra-cflags=<flags>` - Append these flags when compiling JDK C |
|
665 |
files |
|
666 |
* `--with-extra-cxxflags=<flags>` - Append these flags when compiling JDK C++ |
|
667 |
files |
|
668 |
* `--with-extra-ldflags=<flags>` - Append these flags when linking JDK |
|
669 |
libraries |
|
33030 | 670 |
|
45763 | 671 |
#### Configure Arguments for External Dependencies |
44078
673240c54c2e
8176509: Use pandoc for converting build readme to html
ihse
parents:
41040
diff
changeset
|
672 |
|
45763 | 673 |
* `--with-boot-jdk=<path>` - Set the path to the [Boot JDK]( |
674 |
#boot-jdk-requirements) |
|
675 |
* `--with-freetype=<path>` - Set the path to [FreeType](#freetype) |
|
676 |
* `--with-cups=<path>` - Set the path to [CUPS](#cups) |
|
677 |
* `--with-x=<path>` - Set the path to [X11](#x11) |
|
678 |
* `--with-alsa=<path>` - Set the path to [ALSA](#alsa) |
|
679 |
* `--with-libffi=<path>` - Set the path to [libffi](#libffi) |
|
680 |
* `--with-jtreg=<path>` - Set the path to JTReg. See [Running Tests]( |
|
681 |
#running-tests) |
|
33030 | 682 |
|
45763 | 683 |
Certain third-party libraries used by OpenJDK (libjpeg, giflib, libpng, lcms |
684 |
and zlib) are included in the OpenJDK repository. The default behavior of the |
|
685 |
OpenJDK build is to use this version of these libraries, but they might be |
|
686 |
replaced by an external version. To do so, specify `system` as the `<source>` |
|
687 |
option in these arguments. (The default is `bundled`). |
|
33030 | 688 |
|
45763 | 689 |
* `--with-libjpeg=<source>` - Use the specified source for libjpeg |
690 |
* `--with-giflib=<source>` - Use the specified source for giflib |
|
691 |
* `--with-libpng=<source>` - Use the specified source for libpng |
|
692 |
* `--with-lcms=<source>` - Use the specified source for lcms |
|
693 |
* `--with-zlib=<source>` - Use the specified source for zlib |
|
33030 | 694 |
|
45763 | 695 |
On Linux, it is possible to select either static or dynamic linking of the C++ |
696 |
runtime. The default is static linking, with dynamic linking as fallback if the |
|
697 |
static library is not found. |
|
698 |
||
699 |
* `--with-stdc++lib=<method>` - Use the specified method (`static`, `dynamic` |
|
700 |
or `default`) for linking the C++ runtime. |
|
701 |
||
702 |
### Configure Control Variables |
|
33030 | 703 |
|
45763 | 704 |
It is possible to control certain aspects of `configure` by overriding the |
705 |
value of `configure` variables, either on the command line or in the |
|
706 |
environment. |
|
33030 | 707 |
|
45763 | 708 |
Normally, this is **not recommended**. If used improperly, it can lead to a |
709 |
broken configuration. Unless you're well versed in the build system, this is |
|
710 |
hard to use properly. Therefore, `configure` will print a warning if this is |
|
711 |
detected. |
|
33030 | 712 |
|
45763 | 713 |
However, there are a few `configure` variables, known as *control variables* |
714 |
that are supposed to be overriden on the command line. These are variables that |
|
715 |
describe the location of tools needed by the build, like `MAKE` or `GREP`. If |
|
716 |
any such variable is specified, `configure` will use that value instead of |
|
717 |
trying to autodetect the tool. For instance, `bash configure |
|
718 |
MAKE=/opt/gnumake4.0/bin/make`. |
|
33030 | 719 |
|
45763 | 720 |
If a configure argument exists, use that instead, e.g. use `--with-jtreg` |
721 |
instead of setting `JTREGEXE`. |
|
722 |
||
723 |
Also note that, despite what autoconf claims, setting `CFLAGS` will not |
|
724 |
accomplish anything. Instead use `--with-extra-cflags` (and similar for |
|
725 |
`cxxflags` and `ldflags`). |
|
726 |
||
727 |
## Running Make |
|
33030 | 728 |
|
45763 | 729 |
When you have a proper configuration, all you need to do to build OpenJDK is to |
730 |
run `make`. (But see the warning at [GNU Make](#gnu-make) about running the |
|
731 |
correct version of make.) |
|
33030 | 732 |
|
45763 | 733 |
When running `make` without any arguments, the default target is used, which is |
734 |
the same as running `make default` or `make jdk`. This will build a minimal (or |
|
735 |
roughly minimal) set of compiled output (known as an "exploded image") needed |
|
736 |
for a developer to actually execute the newly built JDK. The idea is that in an |
|
737 |
incremental development fashion, when doing a normal make, you should only |
|
738 |
spend time recompiling what's changed (making it purely incremental) and only |
|
739 |
do the work that's needed to actually run and test your code. |
|
740 |
||
741 |
The output of the exploded image resides in `$BUILD/jdk`. You can test the |
|
742 |
newly built JDK like this: `$BUILD/jdk/bin/java -version`. |
|
33030 | 743 |
|
45763 | 744 |
### Common Make Targets |
33030 | 745 |
|
45763 | 746 |
Apart from the default target, here are some common make targets: |
33030 | 747 |
|
45763 | 748 |
* `hotspot` - Build all of hotspot (but only hotspot) |
749 |
* `hotspot-<variant>` - Build just the specified jvm variant |
|
750 |
* `images` or `product-images` - Build the JRE and JDK images |
|
751 |
* `docs` or `docs-image` - Build the documentation image |
|
752 |
* `test-image` - Build the test image |
|
753 |
* `all` or `all-images` - Build all images (product, docs and test) |
|
754 |
* `bootcycle-images` - Build images twice, second time with newly built JDK |
|
755 |
(good for testing) |
|
756 |
* `clean` - Remove all files generated by make, but not those generated by |
|
757 |
configure |
|
758 |
* `dist-clean` - Remove all files, including configuration |
|
33030 | 759 |
|
45763 | 760 |
Run `make help` to get an up-to-date list of important make targets and make |
761 |
control variables. |
|
33030 | 762 |
|
45763 | 763 |
It is possible to build just a single module, a single phase, or a single phase |
764 |
of a single module, by creating make targets according to these followin |
|
765 |
patterns. A phase can be either of `gensrc`, `gendata`, `copy`, `java`, |
|
766 |
`launchers`, `libs` or `rmic`. See [Using Fine-Grained Make Targets]( |
|
767 |
#using-fine-grained-make-targets) for more details about this functionality. |
|
768 |
||
769 |
* `<phase>` - Build the specified phase and everything it depends on |
|
770 |
* `<module>` - Build the specified module and everything it depends on |
|
771 |
* `<module>-<phase>` - Compile the specified phase for the specified module |
|
772 |
and everything it depends on |
|
33030 | 773 |
|
45763 | 774 |
Similarly, it is possible to clean just a part of the build by creating make |
775 |
targets according to these patterns: |
|
33030 | 776 |
|
45763 | 777 |
* `clean-<outputdir>` - Remove the subdir in the output dir with the name |
778 |
* `clean-<phase>` - Remove all build results related to a certain build |
|
779 |
phase |
|
780 |
* `clean-<module>` - Remove all build results related to a certain module |
|
781 |
* `clean-<module>-<phase>` - Remove all build results related to a certain |
|
782 |
module and phase |
|
44078
673240c54c2e
8176509: Use pandoc for converting build readme to html
ihse
parents:
41040
diff
changeset
|
783 |
|
45763 | 784 |
### Make Control Variables |
785 |
||
786 |
It is possible to control `make` behavior by overriding the value of `make` |
|
787 |
variables, either on the command line or in the environment. |
|
33030 | 788 |
|
45763 | 789 |
Normally, this is **not recommended**. If used improperly, it can lead to a |
790 |
broken build. Unless you're well versed in the build system, this is hard to |
|
791 |
use properly. Therefore, `make` will print a warning if this is detected. |
|
33030 | 792 |
|
45763 | 793 |
However, there are a few `make` variables, known as *control variables* that |
794 |
are supposed to be overriden on the command line. These make up the "make time" |
|
795 |
configuration, as opposed to the "configure time" configuration. |
|
33030 | 796 |
|
45763 | 797 |
#### General Make Control Variables |
33030 | 798 |
|
45763 | 799 |
* `JOBS` - Specify the number of jobs to build with. See [Build |
800 |
Performance](#build-performance). |
|
801 |
* `LOG` - Specify the logging level and functionality. See [Checking the |
|
802 |
Build Log File](#checking-the-build-log-file) |
|
803 |
* `CONF` and `CONF_NAME` - Selecting the configuration(s) to use. See [Using |
|
804 |
Multiple Configurations](#using-multiple-configurations) |
|
33030 | 805 |
|
45763 | 806 |
#### Test Make Control Variables |
33030 | 807 |
|
45763 | 808 |
These make control variables only make sense when running tests. Please see |
809 |
[Testing OpenJDK](testing.html) for details. |
|
33030 | 810 |
|
45763 | 811 |
* `TEST` |
812 |
* `TEST_JOBS` |
|
813 |
* `JTREG` |
|
814 |
* `GTEST` |
|
33030 | 815 |
|
45763 | 816 |
#### Advanced Make Control Variables |
33030 | 817 |
|
45763 | 818 |
These advanced make control variables can be potentially unsafe. See [Hints and |
819 |
Suggestions for Advanced Users](#hints-and-suggestions-for-advanced-users) and |
|
820 |
[Understanding the Build System](#understanding-the-build-system) for details. |
|
33030 | 821 |
|
45763 | 822 |
* `SPEC` |
823 |
* `CONF_CHECK` |
|
824 |
* `COMPARE_BUILD` |
|
825 |
* `JDK_FILTER` |
|
33030 | 826 |
|
45763 | 827 |
## Running Tests |
33030 | 828 |
|
45763 | 829 |
Most of the OpenJDK tests are using the [JTReg](http://openjdk.java.net/jtreg) |
830 |
test framework. Make sure that your configuration knows where to find your |
|
831 |
installation of JTReg. If this is not picked up automatically, use the |
|
832 |
`--with-jtreg=<path to jtreg home>` option to point to the JTReg framework. |
|
833 |
Note that this option should point to the JTReg home, i.e. the top directory, |
|
834 |
containing `lib/jtreg.jar` etc. |
|
33030 | 835 |
|
50267
1582de22e3a1
8198323: testing.md not updated for repository layout change
ihse
parents:
49234
diff
changeset
|
836 |
The [Adoption Group](https://wiki.openjdk.java.net/display/Adoption) provides |
1582de22e3a1
8198323: testing.md not updated for repository layout change
ihse
parents:
49234
diff
changeset
|
837 |
recent builds of jtreg [here]( |
1582de22e3a1
8198323: testing.md not updated for repository layout change
ihse
parents:
49234
diff
changeset
|
838 |
https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact). |
1582de22e3a1
8198323: testing.md not updated for repository layout change
ihse
parents:
49234
diff
changeset
|
839 |
Download the latest `.tar.gz` file, unpack it, and point `--with-jtreg` to the |
1582de22e3a1
8198323: testing.md not updated for repository layout change
ihse
parents:
49234
diff
changeset
|
840 |
`jtreg` directory that you just unpacked. |
1582de22e3a1
8198323: testing.md not updated for repository layout change
ihse
parents:
49234
diff
changeset
|
841 |
|
45763 | 842 |
To execute the most basic tests (tier 1), use: |
843 |
``` |
|
844 |
make run-test-tier1 |
|
845 |
``` |
|
33030 | 846 |
|
45763 | 847 |
For more details on how to run tests, please see the [Testing |
848 |
OpenJDK](testing.html) document. |
|
33030 | 849 |
|
45763 | 850 |
## Cross-compiling |
851 |
||
852 |
Cross-compiling means using one platform (the *build* platform) to generate |
|
853 |
output that can ran on another platform (the *target* platform). |
|
33030 | 854 |
|
45763 | 855 |
The typical reason for cross-compiling is that the build is performed on a more |
856 |
powerful desktop computer, but the resulting binaries will be able to run on a |
|
857 |
different, typically low-performing system. Most of the complications that |
|
858 |
arise when building for embedded is due to this separation of *build* and |
|
859 |
*target* systems. |
|
33030 | 860 |
|
45763 | 861 |
This requires a more complex setup and build procedure. This section assumes |
862 |
you are familiar with cross-compiling in general, and will only deal with the |
|
863 |
particularities of cross-compiling OpenJDK. If you are new to cross-compiling, |
|
864 |
please see the [external links at Wikipedia]( |
|
865 |
https://en.wikipedia.org/wiki/Cross_compiler#External_links) for a good start |
|
866 |
on reading materials. |
|
33030 | 867 |
|
45763 | 868 |
Cross-compiling OpenJDK requires you to be able to build both for the build |
869 |
platform and for the target platform. The reason for the former is that we need |
|
870 |
to build and execute tools during the build process, both native tools and Java |
|
871 |
tools. |
|
33030 | 872 |
|
45763 | 873 |
If all you want to do is to compile a 32-bit version, for the same OS, on a |
874 |
64-bit machine, consider using `--with-target-bits=32` instead of doing a |
|
875 |
full-blown cross-compilation. (While this surely is possible, it's a lot more |
|
876 |
work and will take much longer to build.) |
|
33030 | 877 |
|
45763 | 878 |
### Boot JDK and Build JDK |
33030 | 879 |
|
45763 | 880 |
When cross-compiling, make sure you use a boot JDK that runs on the *build* |
881 |
system, and not on the *target* system. |
|
33030 | 882 |
|
45763 | 883 |
To be able to build, we need a "Build JDK", which is a JDK built from the |
884 |
current sources (that is, the same as the end result of the entire build |
|
885 |
process), but able to run on the *build* system, and not the *target* system. |
|
886 |
(In contrast, the Boot JDK should be from an older release, e.g. JDK 8 when |
|
887 |
building JDK 9.) |
|
33030 | 888 |
|
45763 | 889 |
The build process will create a minimal Build JDK for you, as part of building. |
890 |
To speed up the build, you can use `--with-build-jdk` to `configure` to point |
|
891 |
to a pre-built Build JDK. Please note that the build result is unpredictable, |
|
892 |
and can possibly break in subtle ways, if the Build JDK does not **exactly** |
|
893 |
match the current sources. |
|
894 |
||
895 |
### Specifying the Target Platform |
|
33030 | 896 |
|
45763 | 897 |
You *must* specify the target platform when cross-compiling. Doing so will also |
898 |
automatically turn the build into a cross-compiling mode. The simplest way to |
|
899 |
do this is to use the `--openjdk-target` argument, e.g. |
|
900 |
`--openjdk-target=arm-linux-gnueabihf`. or `--openjdk-target=aarch64-oe-linux`. |
|
901 |
This will automatically set the `--build`, `--host` and `--target` options for |
|
902 |
autoconf, which can otherwise be confusing. (In autoconf terminology, the |
|
903 |
"target" is known as "host", and "target" is used for building a Canadian |
|
904 |
cross-compiler.) |
|
905 |
||
906 |
### Toolchain Considerations |
|
33030 | 907 |
|
45763 | 908 |
You will need two copies of your toolchain, one which generates output that can |
909 |
run on the target system (the normal, or *target*, toolchain), and one that |
|
910 |
generates output that can run on the build system (the *build* toolchain). Note |
|
911 |
that cross-compiling is only supported for gcc at the time being. The gcc |
|
912 |
standard is to prefix cross-compiling toolchains with the target denominator. |
|
913 |
If you follow this standard, `configure` is likely to pick up the toolchain |
|
914 |
correctly. |
|
33030 | 915 |
|
45763 | 916 |
The *build* toolchain will be autodetected just the same way the normal |
917 |
*build*/*target* toolchain will be autodetected when not cross-compiling. If |
|
918 |
this is not what you want, or if the autodetection fails, you can specify a |
|
919 |
devkit containing the *build* toolchain using `--with-build-devkit` to |
|
920 |
`configure`, or by giving `BUILD_CC` and `BUILD_CXX` arguments. |
|
921 |
||
922 |
It is often helpful to locate the cross-compilation tools, headers and |
|
923 |
libraries in a separate directory, outside the normal path, and point out that |
|
924 |
directory to `configure`. Do this by setting the sysroot (`--with-sysroot`) and |
|
925 |
appending the directory when searching for cross-compilations tools |
|
926 |
(`--with-toolchain-path`). As a compact form, you can also use `--with-devkit` |
|
927 |
to point to a single directory, if it is correctly setup. (See `basics.m4` for |
|
928 |
details.) |
|
929 |
||
930 |
If you are unsure what toolchain and versions to use, these have been proved |
|
931 |
working at the time of writing: |
|
33030 | 932 |
|
45763 | 933 |
* [aarch64]( |
934 |
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2013.11_linux.tar.xz) |
|
935 |
* [arm 32-bit hardware floating point]( |
|
936 |
https://launchpad.net/linaro-toolchain-unsupported/trunk/2012.09/+download/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux.tar.bz2) |
|
937 |
||
938 |
### Native Libraries |
|
939 |
||
940 |
You will need copies of external native libraries for the *target* system, |
|
941 |
present on the *build* machine while building. |
|
33030 | 942 |
|
45763 | 943 |
Take care not to replace the *build* system's version of these libraries by |
944 |
mistake, since that can render the *build* machine unusable. |
|
33030 | 945 |
|
45763 | 946 |
Make sure that the libraries you point to (ALSA, X11, etc) are for the |
947 |
*target*, not the *build*, platform. |
|
948 |
||
949 |
#### ALSA |
|
950 |
||
951 |
You will need alsa libraries suitable for your *target* system. For most cases, |
|
952 |
using Debian's pre-built libraries work fine. |
|
33030 | 953 |
|
45763 | 954 |
Note that alsa is needed even if you only want to build a headless JDK. |
955 |
||
956 |
* Go to [Debian Package Search](https://www.debian.org/distrib/packages) and |
|
957 |
search for the `libasound2` and `libasound2-dev` packages for your *target* |
|
958 |
system. Download them to /tmp. |
|
33030 | 959 |
|
45763 | 960 |
* Install the libraries into the cross-compilation toolchain. For instance: |
961 |
``` |
|
962 |
cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc |
|
963 |
dpkg-deb -x /tmp/libasound2_1.0.25-4_armhf.deb . |
|
964 |
dpkg-deb -x /tmp/libasound2-dev_1.0.25-4_armhf.deb . |
|
965 |
``` |
|
33030 | 966 |
|
45763 | 967 |
* If alsa is not properly detected by `configure`, you can point it out by |
968 |
`--with-alsa`. |
|
969 |
||
970 |
#### X11 |
|
971 |
||
972 |
You will need X11 libraries suitable for your *target* system. For most cases, |
|
973 |
using Debian's pre-built libraries work fine. |
|
974 |
||
975 |
Note that X11 is needed even if you only want to build a headless JDK. |
|
33030 | 976 |
|
45763 | 977 |
* Go to [Debian Package Search](https://www.debian.org/distrib/packages), |
978 |
search for the following packages for your *target* system, and download them |
|
979 |
to /tmp/target-x11: |
|
980 |
* libxi |
|
981 |
* libxi-dev |
|
982 |
* x11proto-core-dev |
|
983 |
* x11proto-input-dev |
|
984 |
* x11proto-kb-dev |
|
985 |
* x11proto-render-dev |
|
986 |
* x11proto-xext-dev |
|
987 |
* libice-dev |
|
988 |
* libxrender |
|
989 |
* libxrender-dev |
|
990 |
* libsm-dev |
|
991 |
* libxt-dev |
|
992 |
* libx11 |
|
993 |
* libx11-dev |
|
994 |
* libxtst |
|
995 |
* libxtst-dev |
|
996 |
* libxext |
|
997 |
* libxext-dev |
|
33030 | 998 |
|
45763 | 999 |
* Install the libraries into the cross-compilation toolchain. For instance: |
1000 |
``` |
|
1001 |
cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc/usr |
|
1002 |
mkdir X11R6 |
|
1003 |
cd X11R6 |
|
1004 |
for deb in /tmp/target-x11/*.deb ; do dpkg-deb -x $deb . ; done |
|
1005 |
mv usr/* . |
|
1006 |
cd lib |
|
1007 |
cp arm-linux-gnueabihf/* . |
|
1008 |
``` |
|
33030 | 1009 |
|
45763 | 1010 |
You can ignore the following messages. These libraries are not needed to |
1011 |
successfully complete a full JDK build. |
|
1012 |
``` |
|
1013 |
cp: cannot stat `arm-linux-gnueabihf/libICE.so': No such file or directory |
|
1014 |
cp: cannot stat `arm-linux-gnueabihf/libSM.so': No such file or directory |
|
1015 |
cp: cannot stat `arm-linux-gnueabihf/libXt.so': No such file or directory |
|
1016 |
``` |
|
1017 |
||
1018 |
* If the X11 libraries are not properly detected by `configure`, you can |
|
1019 |
point them out by `--with-x`. |
|
1020 |
||
1021 |
### Building for ARM/aarch64 |
|
1022 |
||
1023 |
A common cross-compilation target is the ARM CPU. When building for ARM, it is |
|
1024 |
useful to set the ABI profile. A number of pre-defined ABI profiles are |
|
1025 |
available using `--with-abi-profile`: arm-vfp-sflt, arm-vfp-hflt, arm-sflt, |
|
1026 |
armv5-vfp-sflt, armv6-vfp-hflt. Note that soft-float ABIs are no longer |
|
1027 |
properly supported on OpenJDK. |
|
33030 | 1028 |
|
45763 | 1029 |
OpenJDK contains two different ports for the aarch64 platform, one is the |
1030 |
original aarch64 port from the [AArch64 Port Project]( |
|
1031 |
http://openjdk.java.net/projects/aarch64-port) and one is a 64-bit version of |
|
1032 |
the Oracle contributed ARM port. When targeting aarch64, by the default the |
|
1033 |
original aarch64 port is used. To select the Oracle ARM 64 port, use |
|
1034 |
`--with-cpu-port=arm64`. Also set the corresponding value (`aarch64` or |
|
1035 |
`arm64`) to --with-abi-profile, to ensure a consistent build. |
|
1036 |
||
1037 |
### Verifying the Build |
|
33030 | 1038 |
|
45763 | 1039 |
The build will end up in a directory named like |
1040 |
`build/linux-arm-normal-server-release`. |
|
33030 | 1041 |
|
45763 | 1042 |
Inside this build output directory, the `images/jdk` and `images/jre` will |
1043 |
contain the newly built JDK and JRE, respectively, for your *target* system. |
|
1044 |
||
1045 |
Copy these folders to your *target* system. Then you can run e.g. |
|
1046 |
`images/jdk/bin/java -version`. |
|
1047 |
||
1048 |
## Build Performance |
|
33030 | 1049 |
|
1050 |
Building OpenJDK requires a lot of horsepower. Some of the build tools can be |
|
1051 |
adjusted to utilize more or less of resources such as parallel threads and |
|
1052 |
memory. The `configure` script analyzes your system and selects reasonable |
|
1053 |
values for such options based on your hardware. If you encounter resource |
|
1054 |
problems, such as out of memory conditions, you can modify the detected values |
|
1055 |
with: |
|
1056 |
||
45763 | 1057 |
* `--with-num-cores` -- number of cores in the build system, e.g. |
1058 |
`--with-num-cores=8`. |
|
1059 |
||
1060 |
* `--with-memory-size` -- memory (in MB) available in the build system, e.g. |
|
1061 |
`--with-memory-size=1024` |
|
33030 | 1062 |
|
45763 | 1063 |
You can also specify directly the number of build jobs to use with |
1064 |
`--with-jobs=N` to `configure`, or `JOBS=N` to `make`. Do not use the `-j` flag |
|
1065 |
to `make`. In most cases it will be ignored by the makefiles, but it can cause |
|
1066 |
problems for some make targets. |
|
33030 | 1067 |
|
45763 | 1068 |
It might also be necessary to specify the JVM arguments passed to the Boot JDK, |
1069 |
using e.g. `--with-boot-jdk-jvmargs="-Xmx8G"`. Doing so will override the |
|
1070 |
default JVM arguments passed to the Boot JDK. |
|
33030 | 1071 |
|
1072 |
At the end of a successful execution of `configure`, you will get a performance |
|
1073 |
summary, indicating how well the build will perform. Here you will also get |
|
1074 |
performance hints. If you want to build fast, pay attention to those! |
|
1075 |
||
45763 | 1076 |
If you want to tweak build performance, run with `make LOG=info` to get a build |
1077 |
time summary at the end of the build process. |
|
1078 |
||
1079 |
### Disk Speed |
|
1080 |
||
1081 |
If you are using network shares, e.g. via NFS, for your source code, make sure |
|
1082 |
the build directory is situated on local disk (e.g. by `ln -s |
|
1083 |
/localdisk/jdk-build $JDK-SHARE/build`). The performance penalty is extremely |
|
1084 |
high for building on a network share; close to unusable. |
|
1085 |
||
1086 |
Also, make sure that your build tools (including Boot JDK and toolchain) is |
|
1087 |
located on a local disk and not a network share. |
|
1088 |
||
1089 |
As has been stressed elsewhere, do use SSD for source code and build directory, |
|
1090 |
as well as (if possible) the build tools. |
|
1091 |
||
1092 |
### Virus Checking |
|
1093 |
||
1094 |
The use of virus checking software, especially on Windows, can *significantly* |
|
1095 |
slow down building of OpenJDK. If possible, turn off such software, or exclude |
|
1096 |
the directory containing the OpenJDK source code from on-the-fly checking. |
|
1097 |
||
1098 |
### Ccache |
|
33030 | 1099 |
|
1100 |
The OpenJDK build supports building with ccache when using gcc or clang. Using |
|
1101 |
ccache can radically speed up compilation of native code if you often rebuild |
|
45763 | 1102 |
the same sources. Your milage may vary however, so we recommend evaluating it |
33030 | 1103 |
for yourself. To enable it, make sure it's on the path and configure with |
1104 |
`--enable-ccache`. |
|
1105 |
||
45763 | 1106 |
### Precompiled Headers |
1107 |
||
1108 |
By default, the Hotspot build uses preccompiled headers (PCH) on the toolchains |
|
1109 |
were it is properly supported (clang, gcc, and Visual Studio). Normally, this |
|
1110 |
speeds up the build process, but in some circumstances, it can actually slow |
|
1111 |
things down. |
|
33030 | 1112 |
|
45763 | 1113 |
You can experiment by disabling precompiled headers using |
1114 |
`--disable-precompiled-headers`. |
|
1115 |
||
1116 |
### Icecc / icecream |
|
33030 | 1117 |
|
45763 | 1118 |
[icecc/icecream](http://github.com/icecc/icecream) is a simple way to setup a |
1119 |
distributed compiler network. If you have multiple machines available for |
|
1120 |
building OpenJDK, you can drastically cut individual build times by utilizing |
|
1121 |
it. |
|
33030 | 1122 |
|
45763 | 1123 |
To use, setup an icecc network, and install icecc on the build machine. Then |
1124 |
run `configure` using `--enable-icecc`. |
|
1125 |
||
1126 |
### Using sjavac |
|
1127 |
||
1128 |
To speed up Java compilation, especially incremental compilations, you can try |
|
1129 |
the experimental sjavac compiler by using `--enable-sjavac`. |
|
33030 | 1130 |
|
45763 | 1131 |
### Building the Right Target |
1132 |
||
1133 |
Selecting the proper target to build can have dramatic impact on build time. |
|
1134 |
For normal usage, `jdk` or the default target is just fine. You only need to |
|
1135 |
build `images` for shipping, or if your tests require it. |
|
1136 |
||
1137 |
See also [Using Fine-Grained Make Targets](#using-fine-grained-make-targets) on |
|
1138 |
how to build an even smaller subset of the product. |
|
1139 |
||
1140 |
## Troubleshooting |
|
33030 | 1141 |
|
45763 | 1142 |
If your build fails, it can sometimes be difficult to pinpoint the problem or |
1143 |
find a proper solution. |
|
1144 |
||
1145 |
### Locating the Source of the Error |
|
33030 | 1146 |
|
45763 | 1147 |
When a build fails, it can be hard to pinpoint the actual cause of the error. |
1148 |
In a typical build process, different parts of the product build in parallel, |
|
1149 |
with the output interlaced. |
|
1150 |
||
1151 |
#### Build Failure Summary |
|
1152 |
||
1153 |
To help you, the build system will print a failure summary at the end. It looks |
|
1154 |
like this: |
|
1155 |
||
1156 |
``` |
|
1157 |
ERROR: Build failed for target 'hotspot' in configuration 'linux-x64' (exit code 2) |
|
33030 | 1158 |
|
45763 | 1159 |
=== Output from failing command(s) repeated here === |
1160 |
* For target hotspot_variant-server_libjvm_objs_psMemoryPool.o: |
|
1161 |
/localhome/hg/jdk9-sandbox/hotspot/src/share/vm/services/psMemoryPool.cpp:1:1: error: 'failhere' does not name a type |
|
1162 |
... (rest of output omitted) |
|
33030 | 1163 |
|
45763 | 1164 |
* All command lines available in /localhome/hg/jdk9-sandbox/build/linux-x64/make-support/failure-logs. |
1165 |
=== End of repeated output === |
|
33030 | 1166 |
|
45763 | 1167 |
=== Make failed targets repeated here === |
1168 |
lib/CompileJvm.gmk:207: recipe for target '/localhome/hg/jdk9-sandbox/build/linux-x64/hotspot/variant-server/libjvm/objs/psMemoryPool.o' failed |
|
1169 |
make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed |
|
1170 |
=== End of repeated output === |
|
33030 | 1171 |
|
45763 | 1172 |
Hint: Try searching the build log for the name of the first failed target. |
1173 |
Hint: If caused by a warning, try configure --disable-warnings-as-errors. |
|
1174 |
``` |
|
33030 | 1175 |
|
45763 | 1176 |
Let's break it down! First, the selected configuration, and the top-level |
1177 |
target you entered on the command line that caused the failure is printed. |
|
33030 | 1178 |
|
45763 | 1179 |
Then, between the `Output from failing command(s) repeated here` and `End of |
1180 |
repeated output` the first lines of output (stdout and stderr) from the actual |
|
1181 |
failing command is repeated. In most cases, this is the error message that |
|
1182 |
caused the build to fail. If multiple commands were failing (this can happen in |
|
1183 |
a parallel build), output from all failed commands will be printed here. |
|
1184 |
||
1185 |
The path to the `failure-logs` directory is printed. In this file you will find |
|
1186 |
a `<target>.log` file that contains the output from this command in its |
|
1187 |
entirety, and also a `<target>.cmd`, which contain the complete command line |
|
1188 |
used for running this command. You can re-run the failing command by executing |
|
1189 |
`. <path to failure-logs>/<target>.cmd` in your shell. |
|
33030 | 1190 |
|
45763 | 1191 |
Another way to trace the failure is to follow the chain of make targets, from |
1192 |
top-level targets to individual file targets. Between `Make failed targets |
|
1193 |
repeated here` and `End of repeated output` the output from make showing this |
|
1194 |
chain is repeated. The first failed recipe will typically contain the full path |
|
1195 |
to the file in question that failed to compile. Following lines will show a |
|
1196 |
trace of make targets why we ended up trying to compile that file. |
|
1197 |
||
1198 |
Finally, some hints are given on how to locate the error in the complete log. |
|
1199 |
In this example, we would try searching the log file for "`psMemoryPool.o`". |
|
1200 |
Another way to quickly locate make errors in the log is to search for "`] |
|
1201 |
Error`" or "`***`". |
|
33030 | 1202 |
|
45763 | 1203 |
Note that the build failure summary will only help you if the issue was a |
1204 |
compilation failure or similar. If the problem is more esoteric, or is due to |
|
1205 |
errors in the build machinery, you will likely get empty output logs, and `No |
|
1206 |
indication of failed target found` instead of the make target chain. |
|
1207 |
||
1208 |
#### Checking the Build Log File |
|
1209 |
||
1210 |
The output (stdout and stderr) from the latest build is always stored in |
|
1211 |
`$BUILD/build.log`. The previous build log is stored as `build.log.old`. This |
|
1212 |
means that it is not necessary to redirect the build output yourself if you |
|
1213 |
want to process it. |
|
33030 | 1214 |
|
45763 | 1215 |
You can increase the verbosity of the log file, by the `LOG` control variable |
1216 |
to `make`. If you want to see the command lines used in compilations, use |
|
1217 |
`LOG=cmdlines`. To increase the general verbosity, use `LOG=info`, `LOG=debug` |
|
1218 |
or `LOG=trace`. Both of these can be combined with `cmdlines`, e.g. |
|
1219 |
`LOG=info,cmdlines`. The `debug` log level will show most shell commands |
|
1220 |
executed by make, and `trace` will show all. Beware that both these log levels |
|
1221 |
will produce a massive build log! |
|
1222 |
||
1223 |
### Fixing Unexpected Build Failures |
|
33030 | 1224 |
|
45763 | 1225 |
Most of the time, the build will fail due to incorrect changes in the source |
1226 |
code. |
|
1227 |
||
1228 |
Sometimes the build can fail with no apparent changes that have caused the |
|
1229 |
failure. If this is the first time you are building OpenJDK on this particular |
|
1230 |
computer, and the build fails, the problem is likely with your build |
|
1231 |
environment. But even if you have previously built OpenJDK with success, and it |
|
1232 |
now fails, your build environment might have changed (perhaps due to OS |
|
1233 |
upgrades or similar). But most likely, such failures are due to problems with |
|
1234 |
the incremental rebuild. |
|
1235 |
||
1236 |
#### Problems with the Build Environment |
|
33030 | 1237 |
|
45763 | 1238 |
Make sure your configuration is correct. Re-run `configure`, and look for any |
1239 |
warnings. Warnings that appear in the middle of the `configure` output is also |
|
1240 |
repeated at the end, after the summary. The entire log is stored in |
|
1241 |
`$BUILD/configure.log`. |
|
33030 | 1242 |
|
45763 | 1243 |
Verify that the summary at the end looks correct. Are you indeed using the Boot |
1244 |
JDK and native toolchain that you expect? |
|
33030 | 1245 |
|
45763 | 1246 |
By default, OpenJDK has a strict approach where warnings from the compiler is |
1247 |
considered errors which fail the build. For very new or very old compiler |
|
1248 |
versions, this can trigger new classes of warnings, which thus fails the build. |
|
1249 |
Run `configure` with `--disable-warnings-as-errors` to turn of this behavior. |
|
1250 |
(The warnings will still show, but not make the build fail.) |
|
33030 | 1251 |
|
45763 | 1252 |
#### Problems with Incremental Rebuilds |
33030 | 1253 |
|
45763 | 1254 |
Incremental rebuilds mean that when you modify part of the product, only the |
1255 |
affected parts get rebuilt. While this works great in most cases, and |
|
1256 |
significantly speed up the development process, from time to time complex |
|
1257 |
interdependencies will result in an incorrect build result. This is the most |
|
1258 |
common cause for unexpected build problems, together with inconsistencies |
|
1259 |
between the different Mercurial repositories in the forest. |
|
33030 | 1260 |
|
45763 | 1261 |
Here are a suggested list of things to try if you are having unexpected build |
1262 |
problems. Each step requires more time than the one before, so try them in |
|
1263 |
order. Most issues will be solved at step 1 or 2. |
|
1264 |
||
1265 |
1. Make sure your forest is up-to-date |
|
1266 |
||
1267 |
Run `bash get_source.sh` to make sure you have the latest version of all |
|
1268 |
repositories. |
|
1269 |
||
1270 |
2. Clean build results |
|
1271 |
||
1272 |
The simplest way to fix incremental rebuild issues is to run `make clean`. |
|
1273 |
This will remove all build results, but not the configuration or any build |
|
1274 |
system support artifacts. In most cases, this will solve build errors |
|
1275 |
resulting from incremental build mismatches. |
|
33030 | 1276 |
|
45763 | 1277 |
3. Completely clean the build directory. |
1278 |
||
1279 |
If this does not work, the next step is to run `make dist-clean`, or |
|
1280 |
removing the build output directory (`$BUILD`). This will clean all |
|
1281 |
generated output, including your configuration. You will need to re-run |
|
1282 |
`configure` after this step. A good idea is to run `make |
|
1283 |
print-configuration` before running `make dist-clean`, as this will print |
|
1284 |
your current `configure` command line. Here's a way to do this: |
|
33030 | 1285 |
|
45763 | 1286 |
``` |
1287 |
make print-configuration > current-configuration |
|
1288 |
make dist-clean |
|
1289 |
bash configure $(cat current-configuration) |
|
1290 |
make |
|
1291 |
``` |
|
33030 | 1292 |
|
45763 | 1293 |
4. Re-clone the Mercurial forest |
33030 | 1294 |
|
45763 | 1295 |
Sometimes the Mercurial repositories themselves gets in a state that causes |
1296 |
the product to be un-buildable. In such a case, the simplest solution is |
|
1297 |
often the "sledgehammer approach": delete the entire forest, and re-clone |
|
1298 |
it. If you have local changes, save them first to a different location |
|
1299 |
using `hg export`. |
|
1300 |
||
1301 |
### Specific Build Issues |
|
1302 |
||
1303 |
#### Clock Skew |
|
33030 | 1304 |
|
45763 | 1305 |
If you get an error message like this: |
1306 |
``` |
|
1307 |
File 'xxx' has modification time in the future. |
|
1308 |
Clock skew detected. Your build may be incomplete. |
|
1309 |
``` |
|
1310 |
then the clock on your build machine is out of sync with the timestamps on the |
|
1311 |
source files. Other errors, apparently unrelated but in fact caused by the |
|
1312 |
clock skew, can occur along with the clock skew warnings. These secondary |
|
1313 |
errors may tend to obscure the fact that the true root cause of the problem is |
|
1314 |
an out-of-sync clock. |
|
33030 | 1315 |
|
45763 | 1316 |
If you see these warnings, reset the clock on the build machine, run `make |
1317 |
clean` and restart the build. |
|
1318 |
||
1319 |
#### Out of Memory Errors |
|
1320 |
||
1321 |
On Solaris, you might get an error message like this: |
|
1322 |
``` |
|
1323 |
Trouble writing out table to disk |
|
1324 |
``` |
|
1325 |
To solve this, increase the amount of swap space on your build machine. |
|
33030 | 1326 |
|
45763 | 1327 |
On Windows, you might get error messages like this: |
1328 |
``` |
|
1329 |
fatal error - couldn't allocate heap |
|
1330 |
cannot create ... Permission denied |
|
1331 |
spawn failed |
|
1332 |
``` |
|
1333 |
This can be a sign of a Cygwin problem. See the information about solving |
|
1334 |
problems in the [Cygwin](#cygwin) section. Rebooting the computer might help |
|
1335 |
temporarily. |
|
33030 | 1336 |
|
45763 | 1337 |
### Getting Help |
33030 | 1338 |
|
45763 | 1339 |
If none of the suggestions in this document helps you, or if you find what you |
1340 |
believe is a bug in the build system, please contact the Build Group by sending |
|
1341 |
a mail to [build-dev@openjdk.java.net](mailto:build-dev@openjdk.java.net). |
|
1342 |
Please include the relevant parts of the configure and/or build log. |
|
1343 |
||
1344 |
If you need general help or advice about developing for OpenJDK, you can also |
|
1345 |
contact the Adoption Group. See the section on [Contributing to OpenJDK]( |
|
1346 |
#contributing-to-openjdk) for more information. |
|
33030 | 1347 |
|
45763 | 1348 |
## Hints and Suggestions for Advanced Users |
1349 |
||
1350 |
### Setting Up a Forest for Pushing Changes (defpath) |
|
1351 |
||
1352 |
To help you prepare a proper push path for a Mercurial repository, there exists |
|
1353 |
a useful tool known as [defpath]( |
|
1354 |
http://openjdk.java.net/projects/code-tools/defpath). It will help you setup a |
|
1355 |
proper push path for pushing changes to OpenJDK. |
|
33030 | 1356 |
|
45763 | 1357 |
Install the extension by cloning |
1358 |
`http://hg.openjdk.java.net/code-tools/defpath` and updating your `.hgrc` file. |
|
1359 |
Here's one way to do this: |
|
33030 | 1360 |
|
45763 | 1361 |
``` |
1362 |
cd ~ |
|
1363 |
mkdir hg-ext |
|
1364 |
cd hg-ext |
|
1365 |
hg clone http://hg.openjdk.java.net/code-tools/defpath |
|
1366 |
cat << EOT >> ~/.hgrc |
|
1367 |
[extensions] |
|
1368 |
defpath=~/hg-ext/defpath/defpath.py |
|
1369 |
EOT |
|
1370 |
``` |
|
33030 | 1371 |
|
45763 | 1372 |
You can now setup a proper push path using: |
1373 |
``` |
|
1374 |
hg defpath -d -u <your OpenJDK username> |
|
1375 |
``` |
|
33030 | 1376 |
|
45763 | 1377 |
If you also have the `trees` extension installed in Mercurial, you will |
1378 |
automatically get a `tdefpath` command, which is even more useful. By running |
|
1379 |
`hg tdefpath -du <username>` in the top repository of your forest, all repos |
|
1380 |
will get setup automatically. This is the recommended usage. |
|
1381 |
||
1382 |
### Bash Completion |
|
1383 |
||
1384 |
The `configure` and `make` commands tries to play nice with bash command-line |
|
1385 |
completion (using `<tab>` or `<tab><tab>`). To use this functionality, make |
|
1386 |
sure you enable completion in your `~/.bashrc` (see instructions for bash in |
|
1387 |
your operating system). |
|
1388 |
||
1389 |
Make completion will work out of the box, and will complete valid make targets. |
|
1390 |
For instance, typing `make jdk-i<tab>` will complete to `make jdk-image`. |
|
1391 |
||
1392 |
The `configure` script can get completion for options, but for this to work you |
|
1393 |
need to help `bash` on the way. The standard way of running the script, `bash |
|
1394 |
configure`, will not be understood by bash completion. You need `configure` to |
|
1395 |
be the command to run. One way to achieve this is to add a simple helper script |
|
1396 |
to your path: |
|
33030 | 1397 |
|
45763 | 1398 |
``` |
1399 |
cat << EOT > /tmp/configure |
|
1400 |
#!/bin/bash |
|
1401 |
if [ \$(pwd) = \$(cd \$(dirname \$0); pwd) ] ; then |
|
1402 |
echo >&2 "Abort: Trying to call configure helper recursively" |
|
1403 |
exit 1 |
|
1404 |
fi |
|
33030 | 1405 |
|
45763 | 1406 |
bash \$PWD/configure "\$@" |
1407 |
EOT |
|
1408 |
chmod +x /tmp/configure |
|
1409 |
sudo mv /tmp/configure /usr/local/bin |
|
1410 |
``` |
|
1411 |
||
1412 |
Now `configure --en<tab>-dt<tab>` will result in `configure --enable-dtrace`. |
|
33030 | 1413 |
|
45763 | 1414 |
### Using Multiple Configurations |
33030 | 1415 |
|
45763 | 1416 |
You can have multiple configurations for a single source forest. When you |
1417 |
create a new configuration, run `configure --with-conf-name=<name>` to create a |
|
1418 |
configuration with the name `<name>`. Alternatively, you can create a directory |
|
1419 |
under `build` and run `configure` from there, e.g. `mkdir build/<name> && cd |
|
1420 |
build/<name> && bash ../../configure`. |
|
33030 | 1421 |
|
45763 | 1422 |
Then you can build that configuration using `make CONF_NAME=<name>` or `make |
1423 |
CONF=<pattern>`, where `<pattern>` is a substring matching one or several |
|
1424 |
configurations, e.g. `CONF=debug`. The special empty pattern (`CONF=`) will |
|
1425 |
match *all* available configuration, so `make CONF= hotspot` will build the |
|
1426 |
`hotspot` target for all configurations. Alternatively, you can execute `make` |
|
1427 |
in the configuration directory, e.g. `cd build/<name> && make`. |
|
1428 |
||
1429 |
### Handling Reconfigurations |
|
33030 | 1430 |
|
45763 | 1431 |
If you update the forest and part of the configure script has changed, the |
1432 |
build system will force you to re-run `configure`. |
|
1433 |
||
1434 |
Most of the time, you will be fine by running `configure` again with the same |
|
1435 |
arguments as the last time, which can easily be performed by `make |
|
1436 |
reconfigure`. To simplify this, you can use the `CONF_CHECK` make control |
|
1437 |
variable, either as `make CONF_CHECK=auto`, or by setting an environment |
|
1438 |
variable. For instance, if you add `export CONF_CHECK=auto` to your `.bashrc` |
|
1439 |
file, `make` will always run `reconfigure` automatically whenever the configure |
|
1440 |
script has changed. |
|
33030 | 1441 |
|
45763 | 1442 |
You can also use `CONF_CHECK=ignore` to skip the check for a needed configure |
1443 |
update. This might speed up the build, but comes at the risk of an incorrect |
|
1444 |
build result. This is only recommended if you know what you're doing. |
|
1445 |
||
1446 |
From time to time, you will also need to modify the command line to `configure` |
|
1447 |
due to changes. Use `make print-configure` to show the command line used for |
|
1448 |
your current configuration. |
|
1449 |
||
1450 |
### Using Fine-Grained Make Targets |
|
33030 | 1451 |
|
45763 | 1452 |
The default behavior for make is to create consistent and correct output, at |
1453 |
the expense of build speed, if necessary. |
|
33030 | 1454 |
|
45763 | 1455 |
If you are prepared to take some risk of an incorrect build, and know enough of |
1456 |
the system to understand how things build and interact, you can speed up the |
|
1457 |
build process considerably by instructing make to only build a portion of the |
|
1458 |
product. |
|
1459 |
||
1460 |
#### Building Individual Modules |
|
33030 | 1461 |
|
45763 | 1462 |
The safe way to use fine-grained make targets is to use the module specific |
1463 |
make targets. All source code in JDK 9 is organized so it belongs to a module, |
|
1464 |
e.g. `java.base` or `jdk.jdwp.agent`. You can build only a specific module, by |
|
1465 |
giving it as make target: `make jdk.jdwp.agent`. If the specified module |
|
1466 |
depends on other modules (e.g. `java.base`), those modules will be built first. |
|
33030 | 1467 |
|
45763 | 1468 |
You can also specify a set of modules, just as you can always specify a set of |
1469 |
make targets: `make jdk.crypto.cryptoki jdk.crypto.ec jdk.crypto.mscapi |
|
1470 |
jdk.crypto.ucrypto` |
|
33030 | 1471 |
|
45763 | 1472 |
#### Building Individual Module Phases |
1473 |
||
1474 |
The build process for each module is divided into separate phases. Not all |
|
1475 |
modules need all phases. Which are needed depends on what kind of source code |
|
1476 |
and other artifact the module consists of. The phases are: |
|
33030 | 1477 |
|
45763 | 1478 |
* `gensrc` (Generate source code to compile) |
1479 |
* `gendata` (Generate non-source code artifacts) |
|
1480 |
* `copy` (Copy resource artifacts) |
|
1481 |
* `java` (Compile Java code) |
|
1482 |
* `launchers` (Compile native executables) |
|
1483 |
* `libs` (Compile native libraries) |
|
1484 |
* `rmic` (Run the `rmic` tool) |
|
1485 |
||
1486 |
You can build only a single phase for a module by using the notation |
|
1487 |
`$MODULE-$PHASE`. For instance, to build the `gensrc` phase for `java.base`, |
|
1488 |
use `make java.base-gensrc`. |
|
33030 | 1489 |
|
45763 | 1490 |
Note that some phases may depend on others, e.g. `java` depends on `gensrc` (if |
1491 |
present). Make will build all needed prerequisites before building the |
|
1492 |
requested phase. |
|
1493 |
||
1494 |
#### Skipping the Dependency Check |
|
33030 | 1495 |
|
45763 | 1496 |
When using an iterative development style with frequent quick rebuilds, the |
1497 |
dependency check made by make can take up a significant portion of the time |
|
1498 |
spent on the rebuild. In such cases, it can be useful to bypass the dependency |
|
1499 |
check in make. |
|
1500 |
||
1501 |
> **Note that if used incorrectly, this can lead to a broken build!** |
|
33030 | 1502 |
|
45763 | 1503 |
To achieve this, append `-only` to the build target. For instance, `make |
1504 |
jdk.jdwp.agent-java-only` will *only* build the `java` phase of the |
|
1505 |
`jdk.jdwp.agent` module. If the required dependencies are not present, the |
|
1506 |
build can fail. On the other hand, the execution time measures in milliseconds. |
|
33030 | 1507 |
|
45763 | 1508 |
A useful pattern is to build the first time normally (e.g. `make |
1509 |
jdk.jdwp.agent`) and then on subsequent builds, use the `-only` make target. |
|
1510 |
||
1511 |
#### Rebuilding Part of java.base (JDK\_FILTER) |
|
1512 |
||
1513 |
If you are modifying files in `java.base`, which is the by far largest module |
|
1514 |
in OpenJDK, then you need to rebuild all those files whenever a single file has |
|
1515 |
changed. (This inefficiency will hopefully be addressed in JDK 10.) |
|
44078
673240c54c2e
8176509: Use pandoc for converting build readme to html
ihse
parents:
41040
diff
changeset
|
1516 |
|
45763 | 1517 |
As a hack, you can use the make control variable `JDK_FILTER` to specify a |
1518 |
pattern that will be used to limit the set of files being recompiled. For |
|
1519 |
instance, `make java.base JDK_FILTER=javax/crypto` (or, to combine methods, |
|
1520 |
`make java.base-java-only JDK_FILTER=javax/crypto`) will limit the compilation |
|
1521 |
to files in the `javax.crypto` package. |
|
33030 | 1522 |
|
45763 | 1523 |
### Learn About Mercurial |
1524 |
||
1525 |
To become an efficient OpenJDK developer, it is recommended that you invest in |
|
1526 |
learning Mercurial properly. Here are some links that can get you started: |
|
33030 | 1527 |
|
45763 | 1528 |
* [Mercurial for git users](http://www.mercurial-scm.org/wiki/GitConcepts) |
1529 |
* [The official Mercurial tutorial](http://www.mercurial-scm.org/wiki/Tutorial) |
|
1530 |
* [hg init](http://hginit.com/) |
|
1531 |
* [Mercurial: The Definitive Guide](http://hgbook.red-bean.com/read/) |
|
33030 | 1532 |
|
45763 | 1533 |
## Understanding the Build System |
1534 |
||
1535 |
This section will give you a more technical description on the details of the |
|
1536 |
build system. |
|
1537 |
||
1538 |
### Configurations |
|
33030 | 1539 |
|
45763 | 1540 |
The build system expects to find one or more configuration. These are |
1541 |
technically defined by the `spec.gmk` in a subdirectory to the `build` |
|
1542 |
subdirectory. The `spec.gmk` file is generated by `configure`, and contains in |
|
1543 |
principle the configuration (directly or by files included by `spec.gmk`). |
|
33030 | 1544 |
|
45763 | 1545 |
You can, in fact, select a configuration to build by pointing to the `spec.gmk` |
1546 |
file with the `SPEC` make control variable, e.g. `make SPEC=$BUILD/spec.gmk`. |
|
1547 |
While this is not the recommended way to call `make` as a user, it is what is |
|
1548 |
used under the hood by the build system. |
|
33030 | 1549 |
|
45763 | 1550 |
### Build Output Structure |
1551 |
||
1552 |
The build output for a configuration will end up in `build/<configuration |
|
1553 |
name>`, which we refer to as `$BUILD` in this document. The `$BUILD` directory |
|
1554 |
contains the following important directories: |
|
33030 | 1555 |
|
45763 | 1556 |
``` |
1557 |
buildtools/ |
|
1558 |
configure-support/ |
|
1559 |
hotspot/ |
|
1560 |
images/ |
|
1561 |
jdk/ |
|
1562 |
make-support/ |
|
1563 |
support/ |
|
1564 |
test-results/ |
|
1565 |
test-support/ |
|
1566 |
``` |
|
1567 |
||
1568 |
This is what they are used for: |
|
33030 | 1569 |
|
45763 | 1570 |
* `images`: This is the directory were the output of the `*-image` make |
1571 |
targets end up. For instance, `make jdk-image` ends up in `images/jdk`. |
|
1572 |
||
1573 |
* `jdk`: This is the "exploded image". After `make jdk`, you will be able to |
|
1574 |
launch the newly built JDK by running `$BUILD/jdk/bin/java`. |
|
33030 | 1575 |
|
45763 | 1576 |
* `test-results`: This directory contains the results from running tests. |
33030 | 1577 |
|
45763 | 1578 |
* `support`: This is an area for intermediate files needed during the build, |
1579 |
e.g. generated source code, object files and class files. Some noteworthy |
|
1580 |
directories in `support` is `gensrc`, which contains the generated source |
|
1581 |
code, and the `modules_*` directories, which contains the files in a |
|
1582 |
per-module hierarchy that will later be collapsed into the `jdk` directory |
|
1583 |
of the exploded image. |
|
33030 | 1584 |
|
45763 | 1585 |
* `buildtools`: This is an area for tools compiled for the build platform |
1586 |
that are used during the rest of the build. |
|
1587 |
||
1588 |
* `hotspot`: This is an area for intermediate files needed when building |
|
1589 |
hotspot. |
|
1590 |
||
1591 |
* `configure-support`, `make-support` and `test-support`: These directories |
|
1592 |
contain files that are needed by the build system for `configure`, `make` |
|
1593 |
and for running tests. |
|
33030 | 1594 |
|
45763 | 1595 |
### Fixpath |
1596 |
||
1597 |
Windows path typically look like `C:\User\foo`, while Unix paths look like |
|
1598 |
`/home/foo`. Tools with roots from Unix often experience issues related to this |
|
1599 |
mismatch when running on Windows. |
|
1600 |
||
1601 |
In the OpenJDK build, we always use Unix paths internally, and only just before |
|
1602 |
calling a tool that does not understand Unix paths do we convert them to |
|
1603 |
Windows paths. |
|
33030 | 1604 |
|
45763 | 1605 |
This conversion is done by the `fixpath` tool, which is a small wrapper that |
1606 |
modifies unix-style paths to Windows-style paths in command lines. Fixpath is |
|
1607 |
compiled automatically by `configure`. |
|
33030 | 1608 |
|
45763 | 1609 |
### Native Debug Symbols |
33030 | 1610 |
|
45763 | 1611 |
Native libraries and executables can have debug symbol (and other debug |
1612 |
information) associated with them. How this works is very much platform |
|
1613 |
dependent, but a common problem is that debug symbol information takes a lot of |
|
1614 |
disk space, but is rarely needed by the end user. |
|
33030 | 1615 |
|
45763 | 1616 |
The OpenJDK supports different methods on how to handle debug symbols. The |
1617 |
method used is selected by `--with-native-debug-symbols`, and available methods |
|
1618 |
are `none`, `internal`, `external`, `zipped`. |
|
33030 | 1619 |
|
45763 | 1620 |
* `none` means that no debug symbols will be generated during the build. |
1621 |
||
1622 |
* `internal` means that debug symbols will be generated during the build, and |
|
1623 |
they will be stored in the generated binary. |
|
33030 | 1624 |
|
45763 | 1625 |
* `external` means that debug symbols will be generated during the build, and |
1626 |
after the compilation, they will be moved into a separate `.debuginfo` file. |
|
1627 |
(This was previously known as FDS, Full Debug Symbols). |
|
1628 |
||
1629 |
* `zipped` is like `external`, but the .debuginfo file will also be zipped |
|
1630 |
into a `.diz` file. |
|
33030 | 1631 |
|
45763 | 1632 |
When building for distribution, `zipped` is a good solution. Binaries built |
1633 |
with `internal` is suitable for use by developers, since they facilitate |
|
1634 |
debugging, but should be stripped before distributed to end users. |
|
33030 | 1635 |
|
45763 | 1636 |
### Autoconf Details |
1637 |
||
1638 |
The `configure` script is based on the autoconf framework, but in some details |
|
1639 |
deviate from a normal autoconf `configure` script. |
|
33030 | 1640 |
|
45763 | 1641 |
The `configure` script in the top level directory of OpenJDK is just a thin |
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1642 |
wrapper that calls `make/autoconf/configure`. This in turn will run `autoconf` |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1643 |
to create the runnable (generated) configure script, as |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1644 |
`.build/generated-configure.sh`. Apart from being responsible for the |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1645 |
generation of the runnable script, the `configure` script also provides |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1646 |
functionality that is not easily expressed in the normal Autoconf framework. As |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1647 |
part of this functionality, the generated script is called. |
33030 | 1648 |
|
45763 | 1649 |
The build system will detect if the Autoconf source files have changed, and |
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1650 |
will trigger a regeneration of the generated script if needed. You can also |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1651 |
manually request such an update by `bash configure autogen`. |
33030 | 1652 |
|
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1653 |
In previous versions of the OpenJDK, the generated script was checked in at |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1654 |
`make/autoconf/generated-configure.sh`. This is no longer the case. |
33030 | 1655 |
|
45763 | 1656 |
### Developing the Build System Itself |
33030 | 1657 |
|
45763 | 1658 |
This section contains a few remarks about how to develop for the build system |
1659 |
itself. It is not relevant if you are only making changes in the product source |
|
1660 |
code. |
|
33030 | 1661 |
|
45763 | 1662 |
While technically using `make`, the make source files of the OpenJDK does not |
1663 |
resemble most other Makefiles. Instead of listing specific targets and actions |
|
1664 |
(perhaps using patterns), the basic modus operandi is to call a high-level |
|
1665 |
function (or properly, macro) from the API in `make/common`. For instance, to |
|
1666 |
compile all classes in the `jdk.internal.foo` package in the `jdk.foo` module, |
|
1667 |
a call like this would be made: |
|
33030 | 1668 |
|
45763 | 1669 |
``` |
1670 |
$(eval $(call SetupJavaCompilation, BUILD_FOO_CLASSES, \ |
|
1671 |
SETUP := GENERATE_OLDBYTECODE, \ |
|
47219 | 1672 |
SRC := $(TOPDIR)/src/jkd.foo/share/classes, \ |
45763 | 1673 |
INCLUDES := jdk/internal/foo, \ |
1674 |
BIN := $(SUPPORT_OUTPUTDIR)/foo_classes, \ |
|
1675 |
)) |
|
1676 |
``` |
|
33030 | 1677 |
|
45763 | 1678 |
By encapsulating and expressing the high-level knowledge of *what* should be |
1679 |
done, rather than *how* it should be done (as is normal in Makefiles), we can |
|
1680 |
build a much more powerful and flexible build system. |
|
1681 |
||
1682 |
Correct dependency tracking is paramount. Sloppy dependency tracking will lead |
|
1683 |
to improper parallelization, or worse, race conditions. |
|
33030 | 1684 |
|
45763 | 1685 |
To test for/debug race conditions, try running `make JOBS=1` and `make |
1686 |
JOBS=100` and see if it makes any difference. (It shouldn't). |
|
1687 |
||
1688 |
To compare the output of two different builds and see if, and how, they differ, |
|
1689 |
run `$BUILD1/compare.sh -o $BUILD2`, where `$BUILD1` and `$BUILD2` are the two |
|
1690 |
builds you want to compare. |
|
33030 | 1691 |
|
45763 | 1692 |
To automatically build two consecutive versions and compare them, use |
1693 |
`COMPARE_BUILD`. The value of `COMPARE_BUILD` is a set of variable=value |
|
1694 |
assignments, like this: |
|
1695 |
``` |
|
1696 |
make COMPARE_BUILD=CONF=--enable-new-hotspot-feature:MAKE=hotspot |
|
1697 |
``` |
|
1698 |
See `make/InitSupport.gmk` for details on how to use `COMPARE_BUILD`. |
|
33030 | 1699 |
|
45763 | 1700 |
To analyze build performance, run with `LOG=trace` and check `$BUILD/build-trace-time.log`. |
1701 |
Use `JOBS=1` to avoid parallelism. |
|
33030 | 1702 |
|
45763 | 1703 |
Please check that you adhere to the [Code Conventions for the Build System]( |
1704 |
http://openjdk.java.net/groups/build/doc/code-conventions.html) before |
|
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1705 |
submitting patches. |
45763 | 1706 |
|
1707 |
## Contributing to OpenJDK |
|
1708 |
||
1709 |
So, now you've build your OpenJDK, and made your first patch, and want to |
|
1710 |
contribute it back to the OpenJDK community. |
|
33030 | 1711 |
|
45763 | 1712 |
First of all: Thank you! We gladly welcome your contribution to the OpenJDK. |
1713 |
However, please bear in mind that OpenJDK is a massive project, and we must ask |
|
1714 |
you to follow our rules and guidelines to be able to accept your contribution. |
|
33030 | 1715 |
|
45763 | 1716 |
The official place to start is the ['How to contribute' page]( |
1717 |
http://openjdk.java.net/contribute/). There is also an official (but somewhat |
|
1718 |
outdated and skimpy on details) [Developer's Guide]( |
|
1719 |
http://openjdk.java.net/guide/). |
|
33030 | 1720 |
|
45763 | 1721 |
If this seems overwhelming to you, the Adoption Group is there to help you! A |
1722 |
good place to start is their ['New Contributor' page]( |
|
1723 |
https://wiki.openjdk.java.net/display/Adoption/New+Contributor), or start |
|
1724 |
reading the comprehensive [Getting Started Kit]( |
|
1725 |
https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting-started-kit/en/). The |
|
1726 |
Adoption Group will also happily answer any questions you have about |
|
1727 |
contributing. Contact them by [mail]( |
|
1728 |
http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss) or [IRC]( |
|
1729 |
http://openjdk.java.net/irc/). |
|
33030 | 1730 |
|
45763 | 1731 |
--- |
1732 |
# Override styles from the base CSS file that are not ideal for this document. |
|
1733 |
header-includes: |
|
1734 |
- '<style type="text/css">pre, code, tt { color: #1d6ae5; }</style>' |
|
1735 |
--- |