author | ihse |
Fri, 09 Mar 2018 19:12:07 +0100 | |
changeset 49200 | a19a6228cdb2 |
parent 49159 | 436f1e03fd04 |
child 49234 | 3375a8039fde |
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 |
|
176 |
`configure`. So, use `--with-freetype=/cygdrive/c/freetype` rather than |
|
177 |
`--with-freetype=c:\freetype`. For details on this conversion, see the section |
|
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 |
||
447 |
FreeType2 from [The FreeType Project](http://www.freetype.org/) is required on |
|
448 |
all platforms. At least version 2.3 is required. |
|
33030 | 449 |
|
45763 | 450 |
* To install on an apt-based Linux, try running `sudo apt-get install |
451 |
libcups2-dev`. |
|
452 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
453 |
cups-devel`. |
|
454 |
* To install on Solaris, try running `pkg install system/library/freetype-2`. |
|
455 |
* To install on macOS, try running `brew install freetype`. |
|
456 |
* To install on Windows, see [below](#building-freetype-on-windows). |
|
33030 | 457 |
|
45763 | 458 |
Use `--with-freetype=<path>` if `configure` does not properly locate your |
459 |
FreeType files. |
|
460 |
||
461 |
#### Building FreeType on Windows |
|
462 |
||
463 |
On Windows, there is no readily available compiled version of FreeType. OpenJDK |
|
464 |
can help you compile FreeType from source. Download the FreeType sources and |
|
465 |
unpack them into an arbitrary directory: |
|
33030 | 466 |
|
45763 | 467 |
``` |
468 |
wget http://download.savannah.gnu.org/releases/freetype/freetype-2.5.3.tar.gz |
|
469 |
tar -xzf freetype-2.5.3.tar.gz |
|
470 |
``` |
|
33030 | 471 |
|
45763 | 472 |
Then run `configure` with `--with-freetype-src=<freetype_src>`. This will |
473 |
automatically build the freetype library into `<freetype_src>/lib64` for 64-bit |
|
474 |
builds or into `<freetype_src>/lib32` for 32-bit builds. Afterwards you can |
|
475 |
always use `--with-freetype-include=<freetype_src>/include` and |
|
476 |
`--with-freetype-lib=<freetype_src>/lib[32|64]` for other builds. |
|
33030 | 477 |
|
45763 | 478 |
Alternatively you can unpack the sources like this to use the default |
479 |
directory: |
|
480 |
||
481 |
``` |
|
482 |
tar --one-top-level=$HOME/freetype --strip-components=1 -xzf freetype-2.5.3.tar.gz |
|
483 |
``` |
|
484 |
||
485 |
### CUPS |
|
486 |
||
487 |
CUPS, [Common UNIX Printing System](http://www.cups.org) header files are |
|
488 |
required on all platforms, except Windows. Often these files are provided by |
|
489 |
your operating system. |
|
33030 | 490 |
|
45763 | 491 |
* To install on an apt-based Linux, try running `sudo apt-get install |
492 |
libcups2-dev`. |
|
493 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
494 |
cups-devel`. |
|
495 |
* To install on Solaris, try running `pkg install print/cups`. |
|
33030 | 496 |
|
45763 | 497 |
Use `--with-cups=<path>` if `configure` does not properly locate your CUPS |
498 |
files. |
|
499 |
||
500 |
### X11 |
|
501 |
||
502 |
Certain [X11](http://www.x.org/) libraries and include files are required on |
|
503 |
Linux and Solaris. |
|
33030 | 504 |
|
45763 | 505 |
* To install on an apt-based Linux, try running `sudo apt-get install |
506 |
libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`. |
|
507 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
508 |
libXtst-devel libXt-devel libXrender-devel libXi-devel`. |
|
509 |
* To install on Solaris, try running `pkg install x11/header/x11-protocols |
|
510 |
x11/library/libice x11/library/libpthread-stubs x11/library/libsm |
|
511 |
x11/library/libx11 x11/library/libxau x11/library/libxcb |
|
512 |
x11/library/libxdmcp x11/library/libxevie x11/library/libxext |
|
513 |
x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst |
|
514 |
x11/library/toolkit/libxt`. |
|
515 |
||
516 |
Use `--with-x=<path>` if `configure` does not properly locate your X11 files. |
|
517 |
||
518 |
### ALSA |
|
519 |
||
520 |
ALSA, [Advanced Linux Sound Architecture](https://www.alsa-project.org/) is |
|
521 |
required on Linux. At least version 0.9.1 of ALSA is required. |
|
33030 | 522 |
|
45763 | 523 |
* To install on an apt-based Linux, try running `sudo apt-get install |
524 |
libasound2-dev`. |
|
525 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
526 |
alsa-lib-devel`. |
|
527 |
||
528 |
Use `--with-alsa=<path>` if `configure` does not properly locate your ALSA |
|
529 |
files. |
|
530 |
||
531 |
### libffi |
|
532 |
||
533 |
libffi, the [Portable Foreign Function Interface Library]( |
|
534 |
http://sourceware.org/libffi) is required when building the Zero version of |
|
535 |
Hotspot. |
|
536 |
||
537 |
* To install on an apt-based Linux, try running `sudo apt-get install |
|
538 |
libffi-dev`. |
|
539 |
* To install on an rpm-based Linux, try running `sudo yum install |
|
540 |
libffi-devel`. |
|
541 |
||
542 |
Use `--with-libffi=<path>` if `configure` does not properly locate your libffi |
|
543 |
files. |
|
544 |
||
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
545 |
## Build Tools Requirements |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
546 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
547 |
### Autoconf |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
548 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
549 |
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
|
550 |
platforms. At least version 2.69 is required. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
551 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
552 |
* 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
|
553 |
autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
554 |
* 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
|
555 |
autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
556 |
* To install on macOS, try running `brew install autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
557 |
* 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
|
558 |
-P autoconf`. |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
559 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
560 |
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
|
561 |
specify it using the `AUTOCONF` environment variable, like this: |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
562 |
|
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
563 |
``` |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
564 |
AUTOCONF=<path to autoconf> configure ... |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
565 |
``` |
33030 | 566 |
|
45763 | 567 |
### GNU Make |
568 |
||
569 |
OpenJDK requires [GNU Make](http://www.gnu.org/software/make). No other flavors |
|
570 |
of make are supported. |
|
33030 | 571 |
|
45763 | 572 |
At least version 3.81 of GNU Make must be used. For distributions supporting |
573 |
GNU Make 4.0 or above, we strongly recommend it. GNU Make 4.0 contains useful |
|
574 |
functionality to handle parallel building (supported by `--with-output-sync`) |
|
575 |
and speed and stability improvements. |
|
33030 | 576 |
|
45763 | 577 |
Note that `configure` locates and verifies a properly functioning version of |
578 |
`make` and stores the path to this `make` binary in the configuration. If you |
|
579 |
start a build using `make` on the command line, you will be using the version |
|
580 |
of make found first in your `PATH`, and not necessarily the one stored in the |
|
581 |
configuration. This initial make will be used as "bootstrap make", and in a |
|
582 |
second stage, the make located by `configure` will be called. Normally, this |
|
583 |
will present no issues, but if you have a very old `make`, or a non-GNU Make |
|
584 |
`make` in your path, this might cause issues. |
|
585 |
||
586 |
If you want to override the default make found by `configure`, use the `MAKE` |
|
587 |
configure variable, e.g. `configure MAKE=/opt/gnu/make`. |
|
588 |
||
589 |
On Solaris, it is common to call the GNU version of make by using `gmake`. |
|
590 |
||
591 |
### GNU Bash |
|
33030 | 592 |
|
45763 | 593 |
OpenJDK requires [GNU Bash](http://www.gnu.org/software/bash). No other shells |
594 |
are supported. |
|
595 |
||
596 |
At least version 3.2 of GNU Bash must be used. |
|
597 |
||
598 |
## Running Configure |
|
33030 | 599 |
|
45763 | 600 |
To build OpenJDK, you need a "configuration", which consists of a directory |
601 |
where to store the build output, coupled with information about the platform, |
|
602 |
the specific build machine, and choices that affect how OpenJDK is built. |
|
33030 | 603 |
|
45763 | 604 |
The configuration is created by the `configure` script. The basic invocation of |
605 |
the `configure` script looks like this: |
|
33030 | 606 |
|
45763 | 607 |
``` |
608 |
bash configure [options] |
|
609 |
``` |
|
33030 | 610 |
|
45763 | 611 |
This will create an output directory containing the configuration and setup an |
612 |
area for the build result. This directory typically looks like |
|
613 |
`build/linux-x64-normal-server-release`, but the actual name depends on your |
|
614 |
specific configuration. (It can also be set directly, see [Using Multiple |
|
615 |
Configurations](#using-multiple-configurations)). This directory is referred to |
|
616 |
as `$BUILD` in this documentation. |
|
33030 | 617 |
|
618 |
`configure` will try to figure out what system you are running on and where all |
|
619 |
necessary build components are. If you have all prerequisites for building |
|
620 |
installed, it should find everything. If it fails to detect any component |
|
45763 | 621 |
automatically, it will exit and inform you about the problem. |
33030 | 622 |
|
45763 | 623 |
Some command line examples: |
33030 | 624 |
|
45763 | 625 |
* Create a 32-bit build for Windows with FreeType2 in `C:\freetype-i586`: |
626 |
``` |
|
627 |
bash configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32 |
|
628 |
``` |
|
33030 | 629 |
|
45763 | 630 |
* Create a debug build with the `server` JVM and DTrace enabled: |
631 |
``` |
|
632 |
bash configure --enable-debug --with-jvm-variants=server --enable-dtrace |
|
633 |
``` |
|
33030 | 634 |
|
45763 | 635 |
### Common Configure Arguments |
33030 | 636 |
|
45763 | 637 |
Here follows some of the most common and important `configure` argument. |
33030 | 638 |
|
45763 | 639 |
To get up-to-date information on *all* available `configure` argument, please |
640 |
run: |
|
641 |
``` |
|
642 |
bash configure --help |
|
643 |
``` |
|
33030 | 644 |
|
45763 | 645 |
(Note that this help text also include general autoconf options, like |
646 |
`--dvidir`, that is not relevant to OpenJDK. To list only OpenJDK specific |
|
647 |
features, use `bash configure --help=short` instead.) |
|
648 |
||
649 |
#### Configure Arguments for Tailoring the Build |
|
33030 | 650 |
|
45763 | 651 |
* `--enable-debug` - Set the debug level to `fastdebug` (this is a shorthand |
652 |
for `--with-debug-level=fastdebug`) |
|
653 |
* `--with-debug-level=<level>` - Set the debug level, which can be `release`, |
|
654 |
`fastdebug`, `slowdebug` or `optimized`. Default is `release`. `optimized` |
|
655 |
is variant of `release` with additional Hotspot debug code. |
|
656 |
* `--with-native-debug-symbols=<method>` - Specify if and how native debug |
|
657 |
symbols should be built. Available methods are `none`, `internal`, |
|
658 |
`external`, `zipped`. Default behavior depends on platform. See [Native |
|
659 |
Debug Symbols](#native-debug-symbols) for more details. |
|
660 |
* `--with-version-string=<string>` - Specify the version string this build |
|
661 |
will be identified with. |
|
662 |
* `--with-version-<part>=<value>` - A group of options, where `<part>` can be |
|
663 |
any of `pre`, `opt`, `build`, `major`, `minor`, `security` or `patch`. Use |
|
664 |
these options to modify just the corresponding part of the version string |
|
665 |
from the default, or the value provided by `--with-version-string`. |
|
666 |
* `--with-jvm-variants=<variant>[,<variant>...]` - Build the specified variant |
|
667 |
(or variants) of Hotspot. Valid variants are: `server`, `client`, |
|
47687 | 668 |
`minimal`, `core`, `zero`, `custom`. Note that not all |
45763 | 669 |
variants are possible to combine in a single build. |
670 |
* `--with-jvm-features=<feature>[,<feature>...]` - Use the specified JVM |
|
671 |
features when building Hotspot. The list of features will be enabled on top |
|
672 |
of the default list. For the `custom` JVM variant, this default list is |
|
673 |
empty. A complete list of available JVM features can be found using `bash |
|
674 |
configure --help`. |
|
675 |
* `--with-target-bits=<bits>` - Create a target binary suitable for running |
|
676 |
on a `<bits>` platform. Use this to create 32-bit output on a 64-bit build |
|
677 |
platform, instead of doing a full cross-compile. (This is known as a |
|
678 |
*reduced* build.) |
|
33030 | 679 |
|
45763 | 680 |
#### Configure Arguments for Native Compilation |
33030 | 681 |
|
45763 | 682 |
* `--with-devkit=<path>` - Use this devkit for compilers, tools and resources |
683 |
* `--with-sysroot=<path>` - Use this directory as sysroot |
|
684 |
* `--with-extra-path=<path>[;<path>]` - Prepend these directories to the |
|
685 |
default path when searching for all kinds of binaries |
|
686 |
* `--with-toolchain-path=<path>[;<path>]` - Prepend these directories when |
|
687 |
searching for toolchain binaries (compilers etc) |
|
688 |
* `--with-extra-cflags=<flags>` - Append these flags when compiling JDK C |
|
689 |
files |
|
690 |
* `--with-extra-cxxflags=<flags>` - Append these flags when compiling JDK C++ |
|
691 |
files |
|
692 |
* `--with-extra-ldflags=<flags>` - Append these flags when linking JDK |
|
693 |
libraries |
|
33030 | 694 |
|
45763 | 695 |
#### Configure Arguments for External Dependencies |
44078
673240c54c2e
8176509: Use pandoc for converting build readme to html
ihse
parents:
41040
diff
changeset
|
696 |
|
45763 | 697 |
* `--with-boot-jdk=<path>` - Set the path to the [Boot JDK]( |
698 |
#boot-jdk-requirements) |
|
699 |
* `--with-freetype=<path>` - Set the path to [FreeType](#freetype) |
|
700 |
* `--with-cups=<path>` - Set the path to [CUPS](#cups) |
|
701 |
* `--with-x=<path>` - Set the path to [X11](#x11) |
|
702 |
* `--with-alsa=<path>` - Set the path to [ALSA](#alsa) |
|
703 |
* `--with-libffi=<path>` - Set the path to [libffi](#libffi) |
|
704 |
* `--with-jtreg=<path>` - Set the path to JTReg. See [Running Tests]( |
|
705 |
#running-tests) |
|
33030 | 706 |
|
45763 | 707 |
Certain third-party libraries used by OpenJDK (libjpeg, giflib, libpng, lcms |
708 |
and zlib) are included in the OpenJDK repository. The default behavior of the |
|
709 |
OpenJDK build is to use this version of these libraries, but they might be |
|
710 |
replaced by an external version. To do so, specify `system` as the `<source>` |
|
711 |
option in these arguments. (The default is `bundled`). |
|
33030 | 712 |
|
45763 | 713 |
* `--with-libjpeg=<source>` - Use the specified source for libjpeg |
714 |
* `--with-giflib=<source>` - Use the specified source for giflib |
|
715 |
* `--with-libpng=<source>` - Use the specified source for libpng |
|
716 |
* `--with-lcms=<source>` - Use the specified source for lcms |
|
717 |
* `--with-zlib=<source>` - Use the specified source for zlib |
|
33030 | 718 |
|
45763 | 719 |
On Linux, it is possible to select either static or dynamic linking of the C++ |
720 |
runtime. The default is static linking, with dynamic linking as fallback if the |
|
721 |
static library is not found. |
|
722 |
||
723 |
* `--with-stdc++lib=<method>` - Use the specified method (`static`, `dynamic` |
|
724 |
or `default`) for linking the C++ runtime. |
|
725 |
||
726 |
### Configure Control Variables |
|
33030 | 727 |
|
45763 | 728 |
It is possible to control certain aspects of `configure` by overriding the |
729 |
value of `configure` variables, either on the command line or in the |
|
730 |
environment. |
|
33030 | 731 |
|
45763 | 732 |
Normally, this is **not recommended**. If used improperly, it can lead to a |
733 |
broken configuration. Unless you're well versed in the build system, this is |
|
734 |
hard to use properly. Therefore, `configure` will print a warning if this is |
|
735 |
detected. |
|
33030 | 736 |
|
45763 | 737 |
However, there are a few `configure` variables, known as *control variables* |
738 |
that are supposed to be overriden on the command line. These are variables that |
|
739 |
describe the location of tools needed by the build, like `MAKE` or `GREP`. If |
|
740 |
any such variable is specified, `configure` will use that value instead of |
|
741 |
trying to autodetect the tool. For instance, `bash configure |
|
742 |
MAKE=/opt/gnumake4.0/bin/make`. |
|
33030 | 743 |
|
45763 | 744 |
If a configure argument exists, use that instead, e.g. use `--with-jtreg` |
745 |
instead of setting `JTREGEXE`. |
|
746 |
||
747 |
Also note that, despite what autoconf claims, setting `CFLAGS` will not |
|
748 |
accomplish anything. Instead use `--with-extra-cflags` (and similar for |
|
749 |
`cxxflags` and `ldflags`). |
|
750 |
||
751 |
## Running Make |
|
33030 | 752 |
|
45763 | 753 |
When you have a proper configuration, all you need to do to build OpenJDK is to |
754 |
run `make`. (But see the warning at [GNU Make](#gnu-make) about running the |
|
755 |
correct version of make.) |
|
33030 | 756 |
|
45763 | 757 |
When running `make` without any arguments, the default target is used, which is |
758 |
the same as running `make default` or `make jdk`. This will build a minimal (or |
|
759 |
roughly minimal) set of compiled output (known as an "exploded image") needed |
|
760 |
for a developer to actually execute the newly built JDK. The idea is that in an |
|
761 |
incremental development fashion, when doing a normal make, you should only |
|
762 |
spend time recompiling what's changed (making it purely incremental) and only |
|
763 |
do the work that's needed to actually run and test your code. |
|
764 |
||
765 |
The output of the exploded image resides in `$BUILD/jdk`. You can test the |
|
766 |
newly built JDK like this: `$BUILD/jdk/bin/java -version`. |
|
33030 | 767 |
|
45763 | 768 |
### Common Make Targets |
33030 | 769 |
|
45763 | 770 |
Apart from the default target, here are some common make targets: |
33030 | 771 |
|
45763 | 772 |
* `hotspot` - Build all of hotspot (but only hotspot) |
773 |
* `hotspot-<variant>` - Build just the specified jvm variant |
|
774 |
* `images` or `product-images` - Build the JRE and JDK images |
|
775 |
* `docs` or `docs-image` - Build the documentation image |
|
776 |
* `test-image` - Build the test image |
|
777 |
* `all` or `all-images` - Build all images (product, docs and test) |
|
778 |
* `bootcycle-images` - Build images twice, second time with newly built JDK |
|
779 |
(good for testing) |
|
780 |
* `clean` - Remove all files generated by make, but not those generated by |
|
781 |
configure |
|
782 |
* `dist-clean` - Remove all files, including configuration |
|
33030 | 783 |
|
45763 | 784 |
Run `make help` to get an up-to-date list of important make targets and make |
785 |
control variables. |
|
33030 | 786 |
|
45763 | 787 |
It is possible to build just a single module, a single phase, or a single phase |
788 |
of a single module, by creating make targets according to these followin |
|
789 |
patterns. A phase can be either of `gensrc`, `gendata`, `copy`, `java`, |
|
790 |
`launchers`, `libs` or `rmic`. See [Using Fine-Grained Make Targets]( |
|
791 |
#using-fine-grained-make-targets) for more details about this functionality. |
|
792 |
||
793 |
* `<phase>` - Build the specified phase and everything it depends on |
|
794 |
* `<module>` - Build the specified module and everything it depends on |
|
795 |
* `<module>-<phase>` - Compile the specified phase for the specified module |
|
796 |
and everything it depends on |
|
33030 | 797 |
|
45763 | 798 |
Similarly, it is possible to clean just a part of the build by creating make |
799 |
targets according to these patterns: |
|
33030 | 800 |
|
45763 | 801 |
* `clean-<outputdir>` - Remove the subdir in the output dir with the name |
802 |
* `clean-<phase>` - Remove all build results related to a certain build |
|
803 |
phase |
|
804 |
* `clean-<module>` - Remove all build results related to a certain module |
|
805 |
* `clean-<module>-<phase>` - Remove all build results related to a certain |
|
806 |
module and phase |
|
44078
673240c54c2e
8176509: Use pandoc for converting build readme to html
ihse
parents:
41040
diff
changeset
|
807 |
|
45763 | 808 |
### Make Control Variables |
809 |
||
810 |
It is possible to control `make` behavior by overriding the value of `make` |
|
811 |
variables, either on the command line or in the environment. |
|
33030 | 812 |
|
45763 | 813 |
Normally, this is **not recommended**. If used improperly, it can lead to a |
814 |
broken build. Unless you're well versed in the build system, this is hard to |
|
815 |
use properly. Therefore, `make` will print a warning if this is detected. |
|
33030 | 816 |
|
45763 | 817 |
However, there are a few `make` variables, known as *control variables* that |
818 |
are supposed to be overriden on the command line. These make up the "make time" |
|
819 |
configuration, as opposed to the "configure time" configuration. |
|
33030 | 820 |
|
45763 | 821 |
#### General Make Control Variables |
33030 | 822 |
|
45763 | 823 |
* `JOBS` - Specify the number of jobs to build with. See [Build |
824 |
Performance](#build-performance). |
|
825 |
* `LOG` - Specify the logging level and functionality. See [Checking the |
|
826 |
Build Log File](#checking-the-build-log-file) |
|
827 |
* `CONF` and `CONF_NAME` - Selecting the configuration(s) to use. See [Using |
|
828 |
Multiple Configurations](#using-multiple-configurations) |
|
33030 | 829 |
|
45763 | 830 |
#### Test Make Control Variables |
33030 | 831 |
|
45763 | 832 |
These make control variables only make sense when running tests. Please see |
833 |
[Testing OpenJDK](testing.html) for details. |
|
33030 | 834 |
|
45763 | 835 |
* `TEST` |
836 |
* `TEST_JOBS` |
|
837 |
* `JTREG` |
|
838 |
* `GTEST` |
|
33030 | 839 |
|
45763 | 840 |
#### Advanced Make Control Variables |
33030 | 841 |
|
45763 | 842 |
These advanced make control variables can be potentially unsafe. See [Hints and |
843 |
Suggestions for Advanced Users](#hints-and-suggestions-for-advanced-users) and |
|
844 |
[Understanding the Build System](#understanding-the-build-system) for details. |
|
33030 | 845 |
|
45763 | 846 |
* `SPEC` |
847 |
* `CONF_CHECK` |
|
848 |
* `COMPARE_BUILD` |
|
849 |
* `JDK_FILTER` |
|
33030 | 850 |
|
45763 | 851 |
## Running Tests |
33030 | 852 |
|
45763 | 853 |
Most of the OpenJDK tests are using the [JTReg](http://openjdk.java.net/jtreg) |
854 |
test framework. Make sure that your configuration knows where to find your |
|
855 |
installation of JTReg. If this is not picked up automatically, use the |
|
856 |
`--with-jtreg=<path to jtreg home>` option to point to the JTReg framework. |
|
857 |
Note that this option should point to the JTReg home, i.e. the top directory, |
|
858 |
containing `lib/jtreg.jar` etc. |
|
33030 | 859 |
|
45763 | 860 |
To execute the most basic tests (tier 1), use: |
861 |
``` |
|
862 |
make run-test-tier1 |
|
863 |
``` |
|
33030 | 864 |
|
45763 | 865 |
For more details on how to run tests, please see the [Testing |
866 |
OpenJDK](testing.html) document. |
|
33030 | 867 |
|
45763 | 868 |
## Cross-compiling |
869 |
||
870 |
Cross-compiling means using one platform (the *build* platform) to generate |
|
871 |
output that can ran on another platform (the *target* platform). |
|
33030 | 872 |
|
45763 | 873 |
The typical reason for cross-compiling is that the build is performed on a more |
874 |
powerful desktop computer, but the resulting binaries will be able to run on a |
|
875 |
different, typically low-performing system. Most of the complications that |
|
876 |
arise when building for embedded is due to this separation of *build* and |
|
877 |
*target* systems. |
|
33030 | 878 |
|
45763 | 879 |
This requires a more complex setup and build procedure. This section assumes |
880 |
you are familiar with cross-compiling in general, and will only deal with the |
|
881 |
particularities of cross-compiling OpenJDK. If you are new to cross-compiling, |
|
882 |
please see the [external links at Wikipedia]( |
|
883 |
https://en.wikipedia.org/wiki/Cross_compiler#External_links) for a good start |
|
884 |
on reading materials. |
|
33030 | 885 |
|
45763 | 886 |
Cross-compiling OpenJDK requires you to be able to build both for the build |
887 |
platform and for the target platform. The reason for the former is that we need |
|
888 |
to build and execute tools during the build process, both native tools and Java |
|
889 |
tools. |
|
33030 | 890 |
|
45763 | 891 |
If all you want to do is to compile a 32-bit version, for the same OS, on a |
892 |
64-bit machine, consider using `--with-target-bits=32` instead of doing a |
|
893 |
full-blown cross-compilation. (While this surely is possible, it's a lot more |
|
894 |
work and will take much longer to build.) |
|
33030 | 895 |
|
45763 | 896 |
### Boot JDK and Build JDK |
33030 | 897 |
|
45763 | 898 |
When cross-compiling, make sure you use a boot JDK that runs on the *build* |
899 |
system, and not on the *target* system. |
|
33030 | 900 |
|
45763 | 901 |
To be able to build, we need a "Build JDK", which is a JDK built from the |
902 |
current sources (that is, the same as the end result of the entire build |
|
903 |
process), but able to run on the *build* system, and not the *target* system. |
|
904 |
(In contrast, the Boot JDK should be from an older release, e.g. JDK 8 when |
|
905 |
building JDK 9.) |
|
33030 | 906 |
|
45763 | 907 |
The build process will create a minimal Build JDK for you, as part of building. |
908 |
To speed up the build, you can use `--with-build-jdk` to `configure` to point |
|
909 |
to a pre-built Build JDK. Please note that the build result is unpredictable, |
|
910 |
and can possibly break in subtle ways, if the Build JDK does not **exactly** |
|
911 |
match the current sources. |
|
912 |
||
913 |
### Specifying the Target Platform |
|
33030 | 914 |
|
45763 | 915 |
You *must* specify the target platform when cross-compiling. Doing so will also |
916 |
automatically turn the build into a cross-compiling mode. The simplest way to |
|
917 |
do this is to use the `--openjdk-target` argument, e.g. |
|
918 |
`--openjdk-target=arm-linux-gnueabihf`. or `--openjdk-target=aarch64-oe-linux`. |
|
919 |
This will automatically set the `--build`, `--host` and `--target` options for |
|
920 |
autoconf, which can otherwise be confusing. (In autoconf terminology, the |
|
921 |
"target" is known as "host", and "target" is used for building a Canadian |
|
922 |
cross-compiler.) |
|
923 |
||
924 |
### Toolchain Considerations |
|
33030 | 925 |
|
45763 | 926 |
You will need two copies of your toolchain, one which generates output that can |
927 |
run on the target system (the normal, or *target*, toolchain), and one that |
|
928 |
generates output that can run on the build system (the *build* toolchain). Note |
|
929 |
that cross-compiling is only supported for gcc at the time being. The gcc |
|
930 |
standard is to prefix cross-compiling toolchains with the target denominator. |
|
931 |
If you follow this standard, `configure` is likely to pick up the toolchain |
|
932 |
correctly. |
|
33030 | 933 |
|
45763 | 934 |
The *build* toolchain will be autodetected just the same way the normal |
935 |
*build*/*target* toolchain will be autodetected when not cross-compiling. If |
|
936 |
this is not what you want, or if the autodetection fails, you can specify a |
|
937 |
devkit containing the *build* toolchain using `--with-build-devkit` to |
|
938 |
`configure`, or by giving `BUILD_CC` and `BUILD_CXX` arguments. |
|
939 |
||
940 |
It is often helpful to locate the cross-compilation tools, headers and |
|
941 |
libraries in a separate directory, outside the normal path, and point out that |
|
942 |
directory to `configure`. Do this by setting the sysroot (`--with-sysroot`) and |
|
943 |
appending the directory when searching for cross-compilations tools |
|
944 |
(`--with-toolchain-path`). As a compact form, you can also use `--with-devkit` |
|
945 |
to point to a single directory, if it is correctly setup. (See `basics.m4` for |
|
946 |
details.) |
|
947 |
||
948 |
If you are unsure what toolchain and versions to use, these have been proved |
|
949 |
working at the time of writing: |
|
33030 | 950 |
|
45763 | 951 |
* [aarch64]( |
952 |
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2013.11_linux.tar.xz) |
|
953 |
* [arm 32-bit hardware floating point]( |
|
954 |
https://launchpad.net/linaro-toolchain-unsupported/trunk/2012.09/+download/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux.tar.bz2) |
|
955 |
||
956 |
### Native Libraries |
|
957 |
||
958 |
You will need copies of external native libraries for the *target* system, |
|
959 |
present on the *build* machine while building. |
|
33030 | 960 |
|
45763 | 961 |
Take care not to replace the *build* system's version of these libraries by |
962 |
mistake, since that can render the *build* machine unusable. |
|
33030 | 963 |
|
45763 | 964 |
Make sure that the libraries you point to (ALSA, X11, etc) are for the |
965 |
*target*, not the *build*, platform. |
|
966 |
||
967 |
#### ALSA |
|
968 |
||
969 |
You will need alsa libraries suitable for your *target* system. For most cases, |
|
970 |
using Debian's pre-built libraries work fine. |
|
33030 | 971 |
|
45763 | 972 |
Note that alsa is needed even if you only want to build a headless JDK. |
973 |
||
974 |
* Go to [Debian Package Search](https://www.debian.org/distrib/packages) and |
|
975 |
search for the `libasound2` and `libasound2-dev` packages for your *target* |
|
976 |
system. Download them to /tmp. |
|
33030 | 977 |
|
45763 | 978 |
* Install the libraries into the cross-compilation toolchain. For instance: |
979 |
``` |
|
980 |
cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc |
|
981 |
dpkg-deb -x /tmp/libasound2_1.0.25-4_armhf.deb . |
|
982 |
dpkg-deb -x /tmp/libasound2-dev_1.0.25-4_armhf.deb . |
|
983 |
``` |
|
33030 | 984 |
|
45763 | 985 |
* If alsa is not properly detected by `configure`, you can point it out by |
986 |
`--with-alsa`. |
|
987 |
||
988 |
#### X11 |
|
989 |
||
990 |
You will need X11 libraries suitable for your *target* system. For most cases, |
|
991 |
using Debian's pre-built libraries work fine. |
|
992 |
||
993 |
Note that X11 is needed even if you only want to build a headless JDK. |
|
33030 | 994 |
|
45763 | 995 |
* Go to [Debian Package Search](https://www.debian.org/distrib/packages), |
996 |
search for the following packages for your *target* system, and download them |
|
997 |
to /tmp/target-x11: |
|
998 |
* libxi |
|
999 |
* libxi-dev |
|
1000 |
* x11proto-core-dev |
|
1001 |
* x11proto-input-dev |
|
1002 |
* x11proto-kb-dev |
|
1003 |
* x11proto-render-dev |
|
1004 |
* x11proto-xext-dev |
|
1005 |
* libice-dev |
|
1006 |
* libxrender |
|
1007 |
* libxrender-dev |
|
1008 |
* libsm-dev |
|
1009 |
* libxt-dev |
|
1010 |
* libx11 |
|
1011 |
* libx11-dev |
|
1012 |
* libxtst |
|
1013 |
* libxtst-dev |
|
1014 |
* libxext |
|
1015 |
* libxext-dev |
|
33030 | 1016 |
|
45763 | 1017 |
* Install the libraries into the cross-compilation toolchain. For instance: |
1018 |
``` |
|
1019 |
cd /tools/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc/usr |
|
1020 |
mkdir X11R6 |
|
1021 |
cd X11R6 |
|
1022 |
for deb in /tmp/target-x11/*.deb ; do dpkg-deb -x $deb . ; done |
|
1023 |
mv usr/* . |
|
1024 |
cd lib |
|
1025 |
cp arm-linux-gnueabihf/* . |
|
1026 |
``` |
|
33030 | 1027 |
|
45763 | 1028 |
You can ignore the following messages. These libraries are not needed to |
1029 |
successfully complete a full JDK build. |
|
1030 |
``` |
|
1031 |
cp: cannot stat `arm-linux-gnueabihf/libICE.so': No such file or directory |
|
1032 |
cp: cannot stat `arm-linux-gnueabihf/libSM.so': No such file or directory |
|
1033 |
cp: cannot stat `arm-linux-gnueabihf/libXt.so': No such file or directory |
|
1034 |
``` |
|
1035 |
||
1036 |
* If the X11 libraries are not properly detected by `configure`, you can |
|
1037 |
point them out by `--with-x`. |
|
1038 |
||
1039 |
### Building for ARM/aarch64 |
|
1040 |
||
1041 |
A common cross-compilation target is the ARM CPU. When building for ARM, it is |
|
1042 |
useful to set the ABI profile. A number of pre-defined ABI profiles are |
|
1043 |
available using `--with-abi-profile`: arm-vfp-sflt, arm-vfp-hflt, arm-sflt, |
|
1044 |
armv5-vfp-sflt, armv6-vfp-hflt. Note that soft-float ABIs are no longer |
|
1045 |
properly supported on OpenJDK. |
|
33030 | 1046 |
|
45763 | 1047 |
OpenJDK contains two different ports for the aarch64 platform, one is the |
1048 |
original aarch64 port from the [AArch64 Port Project]( |
|
1049 |
http://openjdk.java.net/projects/aarch64-port) and one is a 64-bit version of |
|
1050 |
the Oracle contributed ARM port. When targeting aarch64, by the default the |
|
1051 |
original aarch64 port is used. To select the Oracle ARM 64 port, use |
|
1052 |
`--with-cpu-port=arm64`. Also set the corresponding value (`aarch64` or |
|
1053 |
`arm64`) to --with-abi-profile, to ensure a consistent build. |
|
1054 |
||
1055 |
### Verifying the Build |
|
33030 | 1056 |
|
45763 | 1057 |
The build will end up in a directory named like |
1058 |
`build/linux-arm-normal-server-release`. |
|
33030 | 1059 |
|
45763 | 1060 |
Inside this build output directory, the `images/jdk` and `images/jre` will |
1061 |
contain the newly built JDK and JRE, respectively, for your *target* system. |
|
1062 |
||
1063 |
Copy these folders to your *target* system. Then you can run e.g. |
|
1064 |
`images/jdk/bin/java -version`. |
|
1065 |
||
1066 |
## Build Performance |
|
33030 | 1067 |
|
1068 |
Building OpenJDK requires a lot of horsepower. Some of the build tools can be |
|
1069 |
adjusted to utilize more or less of resources such as parallel threads and |
|
1070 |
memory. The `configure` script analyzes your system and selects reasonable |
|
1071 |
values for such options based on your hardware. If you encounter resource |
|
1072 |
problems, such as out of memory conditions, you can modify the detected values |
|
1073 |
with: |
|
1074 |
||
45763 | 1075 |
* `--with-num-cores` -- number of cores in the build system, e.g. |
1076 |
`--with-num-cores=8`. |
|
1077 |
||
1078 |
* `--with-memory-size` -- memory (in MB) available in the build system, e.g. |
|
1079 |
`--with-memory-size=1024` |
|
33030 | 1080 |
|
45763 | 1081 |
You can also specify directly the number of build jobs to use with |
1082 |
`--with-jobs=N` to `configure`, or `JOBS=N` to `make`. Do not use the `-j` flag |
|
1083 |
to `make`. In most cases it will be ignored by the makefiles, but it can cause |
|
1084 |
problems for some make targets. |
|
33030 | 1085 |
|
45763 | 1086 |
It might also be necessary to specify the JVM arguments passed to the Boot JDK, |
1087 |
using e.g. `--with-boot-jdk-jvmargs="-Xmx8G"`. Doing so will override the |
|
1088 |
default JVM arguments passed to the Boot JDK. |
|
33030 | 1089 |
|
1090 |
At the end of a successful execution of `configure`, you will get a performance |
|
1091 |
summary, indicating how well the build will perform. Here you will also get |
|
1092 |
performance hints. If you want to build fast, pay attention to those! |
|
1093 |
||
45763 | 1094 |
If you want to tweak build performance, run with `make LOG=info` to get a build |
1095 |
time summary at the end of the build process. |
|
1096 |
||
1097 |
### Disk Speed |
|
1098 |
||
1099 |
If you are using network shares, e.g. via NFS, for your source code, make sure |
|
1100 |
the build directory is situated on local disk (e.g. by `ln -s |
|
1101 |
/localdisk/jdk-build $JDK-SHARE/build`). The performance penalty is extremely |
|
1102 |
high for building on a network share; close to unusable. |
|
1103 |
||
1104 |
Also, make sure that your build tools (including Boot JDK and toolchain) is |
|
1105 |
located on a local disk and not a network share. |
|
1106 |
||
1107 |
As has been stressed elsewhere, do use SSD for source code and build directory, |
|
1108 |
as well as (if possible) the build tools. |
|
1109 |
||
1110 |
### Virus Checking |
|
1111 |
||
1112 |
The use of virus checking software, especially on Windows, can *significantly* |
|
1113 |
slow down building of OpenJDK. If possible, turn off such software, or exclude |
|
1114 |
the directory containing the OpenJDK source code from on-the-fly checking. |
|
1115 |
||
1116 |
### Ccache |
|
33030 | 1117 |
|
1118 |
The OpenJDK build supports building with ccache when using gcc or clang. Using |
|
1119 |
ccache can radically speed up compilation of native code if you often rebuild |
|
45763 | 1120 |
the same sources. Your milage may vary however, so we recommend evaluating it |
33030 | 1121 |
for yourself. To enable it, make sure it's on the path and configure with |
1122 |
`--enable-ccache`. |
|
1123 |
||
45763 | 1124 |
### Precompiled Headers |
1125 |
||
1126 |
By default, the Hotspot build uses preccompiled headers (PCH) on the toolchains |
|
1127 |
were it is properly supported (clang, gcc, and Visual Studio). Normally, this |
|
1128 |
speeds up the build process, but in some circumstances, it can actually slow |
|
1129 |
things down. |
|
33030 | 1130 |
|
45763 | 1131 |
You can experiment by disabling precompiled headers using |
1132 |
`--disable-precompiled-headers`. |
|
1133 |
||
1134 |
### Icecc / icecream |
|
33030 | 1135 |
|
45763 | 1136 |
[icecc/icecream](http://github.com/icecc/icecream) is a simple way to setup a |
1137 |
distributed compiler network. If you have multiple machines available for |
|
1138 |
building OpenJDK, you can drastically cut individual build times by utilizing |
|
1139 |
it. |
|
33030 | 1140 |
|
45763 | 1141 |
To use, setup an icecc network, and install icecc on the build machine. Then |
1142 |
run `configure` using `--enable-icecc`. |
|
1143 |
||
1144 |
### Using sjavac |
|
1145 |
||
1146 |
To speed up Java compilation, especially incremental compilations, you can try |
|
1147 |
the experimental sjavac compiler by using `--enable-sjavac`. |
|
33030 | 1148 |
|
45763 | 1149 |
### Building the Right Target |
1150 |
||
1151 |
Selecting the proper target to build can have dramatic impact on build time. |
|
1152 |
For normal usage, `jdk` or the default target is just fine. You only need to |
|
1153 |
build `images` for shipping, or if your tests require it. |
|
1154 |
||
1155 |
See also [Using Fine-Grained Make Targets](#using-fine-grained-make-targets) on |
|
1156 |
how to build an even smaller subset of the product. |
|
1157 |
||
1158 |
## Troubleshooting |
|
33030 | 1159 |
|
45763 | 1160 |
If your build fails, it can sometimes be difficult to pinpoint the problem or |
1161 |
find a proper solution. |
|
1162 |
||
1163 |
### Locating the Source of the Error |
|
33030 | 1164 |
|
45763 | 1165 |
When a build fails, it can be hard to pinpoint the actual cause of the error. |
1166 |
In a typical build process, different parts of the product build in parallel, |
|
1167 |
with the output interlaced. |
|
1168 |
||
1169 |
#### Build Failure Summary |
|
1170 |
||
1171 |
To help you, the build system will print a failure summary at the end. It looks |
|
1172 |
like this: |
|
1173 |
||
1174 |
``` |
|
1175 |
ERROR: Build failed for target 'hotspot' in configuration 'linux-x64' (exit code 2) |
|
33030 | 1176 |
|
45763 | 1177 |
=== Output from failing command(s) repeated here === |
1178 |
* For target hotspot_variant-server_libjvm_objs_psMemoryPool.o: |
|
1179 |
/localhome/hg/jdk9-sandbox/hotspot/src/share/vm/services/psMemoryPool.cpp:1:1: error: 'failhere' does not name a type |
|
1180 |
... (rest of output omitted) |
|
33030 | 1181 |
|
45763 | 1182 |
* All command lines available in /localhome/hg/jdk9-sandbox/build/linux-x64/make-support/failure-logs. |
1183 |
=== End of repeated output === |
|
33030 | 1184 |
|
45763 | 1185 |
=== Make failed targets repeated here === |
1186 |
lib/CompileJvm.gmk:207: recipe for target '/localhome/hg/jdk9-sandbox/build/linux-x64/hotspot/variant-server/libjvm/objs/psMemoryPool.o' failed |
|
1187 |
make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed |
|
1188 |
=== End of repeated output === |
|
33030 | 1189 |
|
45763 | 1190 |
Hint: Try searching the build log for the name of the first failed target. |
1191 |
Hint: If caused by a warning, try configure --disable-warnings-as-errors. |
|
1192 |
``` |
|
33030 | 1193 |
|
45763 | 1194 |
Let's break it down! First, the selected configuration, and the top-level |
1195 |
target you entered on the command line that caused the failure is printed. |
|
33030 | 1196 |
|
45763 | 1197 |
Then, between the `Output from failing command(s) repeated here` and `End of |
1198 |
repeated output` the first lines of output (stdout and stderr) from the actual |
|
1199 |
failing command is repeated. In most cases, this is the error message that |
|
1200 |
caused the build to fail. If multiple commands were failing (this can happen in |
|
1201 |
a parallel build), output from all failed commands will be printed here. |
|
1202 |
||
1203 |
The path to the `failure-logs` directory is printed. In this file you will find |
|
1204 |
a `<target>.log` file that contains the output from this command in its |
|
1205 |
entirety, and also a `<target>.cmd`, which contain the complete command line |
|
1206 |
used for running this command. You can re-run the failing command by executing |
|
1207 |
`. <path to failure-logs>/<target>.cmd` in your shell. |
|
33030 | 1208 |
|
45763 | 1209 |
Another way to trace the failure is to follow the chain of make targets, from |
1210 |
top-level targets to individual file targets. Between `Make failed targets |
|
1211 |
repeated here` and `End of repeated output` the output from make showing this |
|
1212 |
chain is repeated. The first failed recipe will typically contain the full path |
|
1213 |
to the file in question that failed to compile. Following lines will show a |
|
1214 |
trace of make targets why we ended up trying to compile that file. |
|
1215 |
||
1216 |
Finally, some hints are given on how to locate the error in the complete log. |
|
1217 |
In this example, we would try searching the log file for "`psMemoryPool.o`". |
|
1218 |
Another way to quickly locate make errors in the log is to search for "`] |
|
1219 |
Error`" or "`***`". |
|
33030 | 1220 |
|
45763 | 1221 |
Note that the build failure summary will only help you if the issue was a |
1222 |
compilation failure or similar. If the problem is more esoteric, or is due to |
|
1223 |
errors in the build machinery, you will likely get empty output logs, and `No |
|
1224 |
indication of failed target found` instead of the make target chain. |
|
1225 |
||
1226 |
#### Checking the Build Log File |
|
1227 |
||
1228 |
The output (stdout and stderr) from the latest build is always stored in |
|
1229 |
`$BUILD/build.log`. The previous build log is stored as `build.log.old`. This |
|
1230 |
means that it is not necessary to redirect the build output yourself if you |
|
1231 |
want to process it. |
|
33030 | 1232 |
|
45763 | 1233 |
You can increase the verbosity of the log file, by the `LOG` control variable |
1234 |
to `make`. If you want to see the command lines used in compilations, use |
|
1235 |
`LOG=cmdlines`. To increase the general verbosity, use `LOG=info`, `LOG=debug` |
|
1236 |
or `LOG=trace`. Both of these can be combined with `cmdlines`, e.g. |
|
1237 |
`LOG=info,cmdlines`. The `debug` log level will show most shell commands |
|
1238 |
executed by make, and `trace` will show all. Beware that both these log levels |
|
1239 |
will produce a massive build log! |
|
1240 |
||
1241 |
### Fixing Unexpected Build Failures |
|
33030 | 1242 |
|
45763 | 1243 |
Most of the time, the build will fail due to incorrect changes in the source |
1244 |
code. |
|
1245 |
||
1246 |
Sometimes the build can fail with no apparent changes that have caused the |
|
1247 |
failure. If this is the first time you are building OpenJDK on this particular |
|
1248 |
computer, and the build fails, the problem is likely with your build |
|
1249 |
environment. But even if you have previously built OpenJDK with success, and it |
|
1250 |
now fails, your build environment might have changed (perhaps due to OS |
|
1251 |
upgrades or similar). But most likely, such failures are due to problems with |
|
1252 |
the incremental rebuild. |
|
1253 |
||
1254 |
#### Problems with the Build Environment |
|
33030 | 1255 |
|
45763 | 1256 |
Make sure your configuration is correct. Re-run `configure`, and look for any |
1257 |
warnings. Warnings that appear in the middle of the `configure` output is also |
|
1258 |
repeated at the end, after the summary. The entire log is stored in |
|
1259 |
`$BUILD/configure.log`. |
|
33030 | 1260 |
|
45763 | 1261 |
Verify that the summary at the end looks correct. Are you indeed using the Boot |
1262 |
JDK and native toolchain that you expect? |
|
33030 | 1263 |
|
45763 | 1264 |
By default, OpenJDK has a strict approach where warnings from the compiler is |
1265 |
considered errors which fail the build. For very new or very old compiler |
|
1266 |
versions, this can trigger new classes of warnings, which thus fails the build. |
|
1267 |
Run `configure` with `--disable-warnings-as-errors` to turn of this behavior. |
|
1268 |
(The warnings will still show, but not make the build fail.) |
|
33030 | 1269 |
|
45763 | 1270 |
#### Problems with Incremental Rebuilds |
33030 | 1271 |
|
45763 | 1272 |
Incremental rebuilds mean that when you modify part of the product, only the |
1273 |
affected parts get rebuilt. While this works great in most cases, and |
|
1274 |
significantly speed up the development process, from time to time complex |
|
1275 |
interdependencies will result in an incorrect build result. This is the most |
|
1276 |
common cause for unexpected build problems, together with inconsistencies |
|
1277 |
between the different Mercurial repositories in the forest. |
|
33030 | 1278 |
|
45763 | 1279 |
Here are a suggested list of things to try if you are having unexpected build |
1280 |
problems. Each step requires more time than the one before, so try them in |
|
1281 |
order. Most issues will be solved at step 1 or 2. |
|
1282 |
||
1283 |
1. Make sure your forest is up-to-date |
|
1284 |
||
1285 |
Run `bash get_source.sh` to make sure you have the latest version of all |
|
1286 |
repositories. |
|
1287 |
||
1288 |
2. Clean build results |
|
1289 |
||
1290 |
The simplest way to fix incremental rebuild issues is to run `make clean`. |
|
1291 |
This will remove all build results, but not the configuration or any build |
|
1292 |
system support artifacts. In most cases, this will solve build errors |
|
1293 |
resulting from incremental build mismatches. |
|
33030 | 1294 |
|
45763 | 1295 |
3. Completely clean the build directory. |
1296 |
||
1297 |
If this does not work, the next step is to run `make dist-clean`, or |
|
1298 |
removing the build output directory (`$BUILD`). This will clean all |
|
1299 |
generated output, including your configuration. You will need to re-run |
|
1300 |
`configure` after this step. A good idea is to run `make |
|
1301 |
print-configuration` before running `make dist-clean`, as this will print |
|
1302 |
your current `configure` command line. Here's a way to do this: |
|
33030 | 1303 |
|
45763 | 1304 |
``` |
1305 |
make print-configuration > current-configuration |
|
1306 |
make dist-clean |
|
1307 |
bash configure $(cat current-configuration) |
|
1308 |
make |
|
1309 |
``` |
|
33030 | 1310 |
|
45763 | 1311 |
4. Re-clone the Mercurial forest |
33030 | 1312 |
|
45763 | 1313 |
Sometimes the Mercurial repositories themselves gets in a state that causes |
1314 |
the product to be un-buildable. In such a case, the simplest solution is |
|
1315 |
often the "sledgehammer approach": delete the entire forest, and re-clone |
|
1316 |
it. If you have local changes, save them first to a different location |
|
1317 |
using `hg export`. |
|
1318 |
||
1319 |
### Specific Build Issues |
|
1320 |
||
1321 |
#### Clock Skew |
|
33030 | 1322 |
|
45763 | 1323 |
If you get an error message like this: |
1324 |
``` |
|
1325 |
File 'xxx' has modification time in the future. |
|
1326 |
Clock skew detected. Your build may be incomplete. |
|
1327 |
``` |
|
1328 |
then the clock on your build machine is out of sync with the timestamps on the |
|
1329 |
source files. Other errors, apparently unrelated but in fact caused by the |
|
1330 |
clock skew, can occur along with the clock skew warnings. These secondary |
|
1331 |
errors may tend to obscure the fact that the true root cause of the problem is |
|
1332 |
an out-of-sync clock. |
|
33030 | 1333 |
|
45763 | 1334 |
If you see these warnings, reset the clock on the build machine, run `make |
1335 |
clean` and restart the build. |
|
1336 |
||
1337 |
#### Out of Memory Errors |
|
1338 |
||
1339 |
On Solaris, you might get an error message like this: |
|
1340 |
``` |
|
1341 |
Trouble writing out table to disk |
|
1342 |
``` |
|
1343 |
To solve this, increase the amount of swap space on your build machine. |
|
33030 | 1344 |
|
45763 | 1345 |
On Windows, you might get error messages like this: |
1346 |
``` |
|
1347 |
fatal error - couldn't allocate heap |
|
1348 |
cannot create ... Permission denied |
|
1349 |
spawn failed |
|
1350 |
``` |
|
1351 |
This can be a sign of a Cygwin problem. See the information about solving |
|
1352 |
problems in the [Cygwin](#cygwin) section. Rebooting the computer might help |
|
1353 |
temporarily. |
|
33030 | 1354 |
|
45763 | 1355 |
### Getting Help |
33030 | 1356 |
|
45763 | 1357 |
If none of the suggestions in this document helps you, or if you find what you |
1358 |
believe is a bug in the build system, please contact the Build Group by sending |
|
1359 |
a mail to [build-dev@openjdk.java.net](mailto:build-dev@openjdk.java.net). |
|
1360 |
Please include the relevant parts of the configure and/or build log. |
|
1361 |
||
1362 |
If you need general help or advice about developing for OpenJDK, you can also |
|
1363 |
contact the Adoption Group. See the section on [Contributing to OpenJDK]( |
|
1364 |
#contributing-to-openjdk) for more information. |
|
33030 | 1365 |
|
45763 | 1366 |
## Hints and Suggestions for Advanced Users |
1367 |
||
1368 |
### Setting Up a Forest for Pushing Changes (defpath) |
|
1369 |
||
1370 |
To help you prepare a proper push path for a Mercurial repository, there exists |
|
1371 |
a useful tool known as [defpath]( |
|
1372 |
http://openjdk.java.net/projects/code-tools/defpath). It will help you setup a |
|
1373 |
proper push path for pushing changes to OpenJDK. |
|
33030 | 1374 |
|
45763 | 1375 |
Install the extension by cloning |
1376 |
`http://hg.openjdk.java.net/code-tools/defpath` and updating your `.hgrc` file. |
|
1377 |
Here's one way to do this: |
|
33030 | 1378 |
|
45763 | 1379 |
``` |
1380 |
cd ~ |
|
1381 |
mkdir hg-ext |
|
1382 |
cd hg-ext |
|
1383 |
hg clone http://hg.openjdk.java.net/code-tools/defpath |
|
1384 |
cat << EOT >> ~/.hgrc |
|
1385 |
[extensions] |
|
1386 |
defpath=~/hg-ext/defpath/defpath.py |
|
1387 |
EOT |
|
1388 |
``` |
|
33030 | 1389 |
|
45763 | 1390 |
You can now setup a proper push path using: |
1391 |
``` |
|
1392 |
hg defpath -d -u <your OpenJDK username> |
|
1393 |
``` |
|
33030 | 1394 |
|
45763 | 1395 |
If you also have the `trees` extension installed in Mercurial, you will |
1396 |
automatically get a `tdefpath` command, which is even more useful. By running |
|
1397 |
`hg tdefpath -du <username>` in the top repository of your forest, all repos |
|
1398 |
will get setup automatically. This is the recommended usage. |
|
1399 |
||
1400 |
### Bash Completion |
|
1401 |
||
1402 |
The `configure` and `make` commands tries to play nice with bash command-line |
|
1403 |
completion (using `<tab>` or `<tab><tab>`). To use this functionality, make |
|
1404 |
sure you enable completion in your `~/.bashrc` (see instructions for bash in |
|
1405 |
your operating system). |
|
1406 |
||
1407 |
Make completion will work out of the box, and will complete valid make targets. |
|
1408 |
For instance, typing `make jdk-i<tab>` will complete to `make jdk-image`. |
|
1409 |
||
1410 |
The `configure` script can get completion for options, but for this to work you |
|
1411 |
need to help `bash` on the way. The standard way of running the script, `bash |
|
1412 |
configure`, will not be understood by bash completion. You need `configure` to |
|
1413 |
be the command to run. One way to achieve this is to add a simple helper script |
|
1414 |
to your path: |
|
33030 | 1415 |
|
45763 | 1416 |
``` |
1417 |
cat << EOT > /tmp/configure |
|
1418 |
#!/bin/bash |
|
1419 |
if [ \$(pwd) = \$(cd \$(dirname \$0); pwd) ] ; then |
|
1420 |
echo >&2 "Abort: Trying to call configure helper recursively" |
|
1421 |
exit 1 |
|
1422 |
fi |
|
33030 | 1423 |
|
45763 | 1424 |
bash \$PWD/configure "\$@" |
1425 |
EOT |
|
1426 |
chmod +x /tmp/configure |
|
1427 |
sudo mv /tmp/configure /usr/local/bin |
|
1428 |
``` |
|
1429 |
||
1430 |
Now `configure --en<tab>-dt<tab>` will result in `configure --enable-dtrace`. |
|
33030 | 1431 |
|
45763 | 1432 |
### Using Multiple Configurations |
33030 | 1433 |
|
45763 | 1434 |
You can have multiple configurations for a single source forest. When you |
1435 |
create a new configuration, run `configure --with-conf-name=<name>` to create a |
|
1436 |
configuration with the name `<name>`. Alternatively, you can create a directory |
|
1437 |
under `build` and run `configure` from there, e.g. `mkdir build/<name> && cd |
|
1438 |
build/<name> && bash ../../configure`. |
|
33030 | 1439 |
|
45763 | 1440 |
Then you can build that configuration using `make CONF_NAME=<name>` or `make |
1441 |
CONF=<pattern>`, where `<pattern>` is a substring matching one or several |
|
1442 |
configurations, e.g. `CONF=debug`. The special empty pattern (`CONF=`) will |
|
1443 |
match *all* available configuration, so `make CONF= hotspot` will build the |
|
1444 |
`hotspot` target for all configurations. Alternatively, you can execute `make` |
|
1445 |
in the configuration directory, e.g. `cd build/<name> && make`. |
|
1446 |
||
1447 |
### Handling Reconfigurations |
|
33030 | 1448 |
|
45763 | 1449 |
If you update the forest and part of the configure script has changed, the |
1450 |
build system will force you to re-run `configure`. |
|
1451 |
||
1452 |
Most of the time, you will be fine by running `configure` again with the same |
|
1453 |
arguments as the last time, which can easily be performed by `make |
|
1454 |
reconfigure`. To simplify this, you can use the `CONF_CHECK` make control |
|
1455 |
variable, either as `make CONF_CHECK=auto`, or by setting an environment |
|
1456 |
variable. For instance, if you add `export CONF_CHECK=auto` to your `.bashrc` |
|
1457 |
file, `make` will always run `reconfigure` automatically whenever the configure |
|
1458 |
script has changed. |
|
33030 | 1459 |
|
45763 | 1460 |
You can also use `CONF_CHECK=ignore` to skip the check for a needed configure |
1461 |
update. This might speed up the build, but comes at the risk of an incorrect |
|
1462 |
build result. This is only recommended if you know what you're doing. |
|
1463 |
||
1464 |
From time to time, you will also need to modify the command line to `configure` |
|
1465 |
due to changes. Use `make print-configure` to show the command line used for |
|
1466 |
your current configuration. |
|
1467 |
||
1468 |
### Using Fine-Grained Make Targets |
|
33030 | 1469 |
|
45763 | 1470 |
The default behavior for make is to create consistent and correct output, at |
1471 |
the expense of build speed, if necessary. |
|
33030 | 1472 |
|
45763 | 1473 |
If you are prepared to take some risk of an incorrect build, and know enough of |
1474 |
the system to understand how things build and interact, you can speed up the |
|
1475 |
build process considerably by instructing make to only build a portion of the |
|
1476 |
product. |
|
1477 |
||
1478 |
#### Building Individual Modules |
|
33030 | 1479 |
|
45763 | 1480 |
The safe way to use fine-grained make targets is to use the module specific |
1481 |
make targets. All source code in JDK 9 is organized so it belongs to a module, |
|
1482 |
e.g. `java.base` or `jdk.jdwp.agent`. You can build only a specific module, by |
|
1483 |
giving it as make target: `make jdk.jdwp.agent`. If the specified module |
|
1484 |
depends on other modules (e.g. `java.base`), those modules will be built first. |
|
33030 | 1485 |
|
45763 | 1486 |
You can also specify a set of modules, just as you can always specify a set of |
1487 |
make targets: `make jdk.crypto.cryptoki jdk.crypto.ec jdk.crypto.mscapi |
|
1488 |
jdk.crypto.ucrypto` |
|
33030 | 1489 |
|
45763 | 1490 |
#### Building Individual Module Phases |
1491 |
||
1492 |
The build process for each module is divided into separate phases. Not all |
|
1493 |
modules need all phases. Which are needed depends on what kind of source code |
|
1494 |
and other artifact the module consists of. The phases are: |
|
33030 | 1495 |
|
45763 | 1496 |
* `gensrc` (Generate source code to compile) |
1497 |
* `gendata` (Generate non-source code artifacts) |
|
1498 |
* `copy` (Copy resource artifacts) |
|
1499 |
* `java` (Compile Java code) |
|
1500 |
* `launchers` (Compile native executables) |
|
1501 |
* `libs` (Compile native libraries) |
|
1502 |
* `rmic` (Run the `rmic` tool) |
|
1503 |
||
1504 |
You can build only a single phase for a module by using the notation |
|
1505 |
`$MODULE-$PHASE`. For instance, to build the `gensrc` phase for `java.base`, |
|
1506 |
use `make java.base-gensrc`. |
|
33030 | 1507 |
|
45763 | 1508 |
Note that some phases may depend on others, e.g. `java` depends on `gensrc` (if |
1509 |
present). Make will build all needed prerequisites before building the |
|
1510 |
requested phase. |
|
1511 |
||
1512 |
#### Skipping the Dependency Check |
|
33030 | 1513 |
|
45763 | 1514 |
When using an iterative development style with frequent quick rebuilds, the |
1515 |
dependency check made by make can take up a significant portion of the time |
|
1516 |
spent on the rebuild. In such cases, it can be useful to bypass the dependency |
|
1517 |
check in make. |
|
1518 |
||
1519 |
> **Note that if used incorrectly, this can lead to a broken build!** |
|
33030 | 1520 |
|
45763 | 1521 |
To achieve this, append `-only` to the build target. For instance, `make |
1522 |
jdk.jdwp.agent-java-only` will *only* build the `java` phase of the |
|
1523 |
`jdk.jdwp.agent` module. If the required dependencies are not present, the |
|
1524 |
build can fail. On the other hand, the execution time measures in milliseconds. |
|
33030 | 1525 |
|
45763 | 1526 |
A useful pattern is to build the first time normally (e.g. `make |
1527 |
jdk.jdwp.agent`) and then on subsequent builds, use the `-only` make target. |
|
1528 |
||
1529 |
#### Rebuilding Part of java.base (JDK\_FILTER) |
|
1530 |
||
1531 |
If you are modifying files in `java.base`, which is the by far largest module |
|
1532 |
in OpenJDK, then you need to rebuild all those files whenever a single file has |
|
1533 |
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
|
1534 |
|
45763 | 1535 |
As a hack, you can use the make control variable `JDK_FILTER` to specify a |
1536 |
pattern that will be used to limit the set of files being recompiled. For |
|
1537 |
instance, `make java.base JDK_FILTER=javax/crypto` (or, to combine methods, |
|
1538 |
`make java.base-java-only JDK_FILTER=javax/crypto`) will limit the compilation |
|
1539 |
to files in the `javax.crypto` package. |
|
33030 | 1540 |
|
45763 | 1541 |
### Learn About Mercurial |
1542 |
||
1543 |
To become an efficient OpenJDK developer, it is recommended that you invest in |
|
1544 |
learning Mercurial properly. Here are some links that can get you started: |
|
33030 | 1545 |
|
45763 | 1546 |
* [Mercurial for git users](http://www.mercurial-scm.org/wiki/GitConcepts) |
1547 |
* [The official Mercurial tutorial](http://www.mercurial-scm.org/wiki/Tutorial) |
|
1548 |
* [hg init](http://hginit.com/) |
|
1549 |
* [Mercurial: The Definitive Guide](http://hgbook.red-bean.com/read/) |
|
33030 | 1550 |
|
45763 | 1551 |
## Understanding the Build System |
1552 |
||
1553 |
This section will give you a more technical description on the details of the |
|
1554 |
build system. |
|
1555 |
||
1556 |
### Configurations |
|
33030 | 1557 |
|
45763 | 1558 |
The build system expects to find one or more configuration. These are |
1559 |
technically defined by the `spec.gmk` in a subdirectory to the `build` |
|
1560 |
subdirectory. The `spec.gmk` file is generated by `configure`, and contains in |
|
1561 |
principle the configuration (directly or by files included by `spec.gmk`). |
|
33030 | 1562 |
|
45763 | 1563 |
You can, in fact, select a configuration to build by pointing to the `spec.gmk` |
1564 |
file with the `SPEC` make control variable, e.g. `make SPEC=$BUILD/spec.gmk`. |
|
1565 |
While this is not the recommended way to call `make` as a user, it is what is |
|
1566 |
used under the hood by the build system. |
|
33030 | 1567 |
|
45763 | 1568 |
### Build Output Structure |
1569 |
||
1570 |
The build output for a configuration will end up in `build/<configuration |
|
1571 |
name>`, which we refer to as `$BUILD` in this document. The `$BUILD` directory |
|
1572 |
contains the following important directories: |
|
33030 | 1573 |
|
45763 | 1574 |
``` |
1575 |
buildtools/ |
|
1576 |
configure-support/ |
|
1577 |
hotspot/ |
|
1578 |
images/ |
|
1579 |
jdk/ |
|
1580 |
make-support/ |
|
1581 |
support/ |
|
1582 |
test-results/ |
|
1583 |
test-support/ |
|
1584 |
``` |
|
1585 |
||
1586 |
This is what they are used for: |
|
33030 | 1587 |
|
45763 | 1588 |
* `images`: This is the directory were the output of the `*-image` make |
1589 |
targets end up. For instance, `make jdk-image` ends up in `images/jdk`. |
|
1590 |
||
1591 |
* `jdk`: This is the "exploded image". After `make jdk`, you will be able to |
|
1592 |
launch the newly built JDK by running `$BUILD/jdk/bin/java`. |
|
33030 | 1593 |
|
45763 | 1594 |
* `test-results`: This directory contains the results from running tests. |
33030 | 1595 |
|
45763 | 1596 |
* `support`: This is an area for intermediate files needed during the build, |
1597 |
e.g. generated source code, object files and class files. Some noteworthy |
|
1598 |
directories in `support` is `gensrc`, which contains the generated source |
|
1599 |
code, and the `modules_*` directories, which contains the files in a |
|
1600 |
per-module hierarchy that will later be collapsed into the `jdk` directory |
|
1601 |
of the exploded image. |
|
33030 | 1602 |
|
45763 | 1603 |
* `buildtools`: This is an area for tools compiled for the build platform |
1604 |
that are used during the rest of the build. |
|
1605 |
||
1606 |
* `hotspot`: This is an area for intermediate files needed when building |
|
1607 |
hotspot. |
|
1608 |
||
1609 |
* `configure-support`, `make-support` and `test-support`: These directories |
|
1610 |
contain files that are needed by the build system for `configure`, `make` |
|
1611 |
and for running tests. |
|
33030 | 1612 |
|
45763 | 1613 |
### Fixpath |
1614 |
||
1615 |
Windows path typically look like `C:\User\foo`, while Unix paths look like |
|
1616 |
`/home/foo`. Tools with roots from Unix often experience issues related to this |
|
1617 |
mismatch when running on Windows. |
|
1618 |
||
1619 |
In the OpenJDK build, we always use Unix paths internally, and only just before |
|
1620 |
calling a tool that does not understand Unix paths do we convert them to |
|
1621 |
Windows paths. |
|
33030 | 1622 |
|
45763 | 1623 |
This conversion is done by the `fixpath` tool, which is a small wrapper that |
1624 |
modifies unix-style paths to Windows-style paths in command lines. Fixpath is |
|
1625 |
compiled automatically by `configure`. |
|
33030 | 1626 |
|
45763 | 1627 |
### Native Debug Symbols |
33030 | 1628 |
|
45763 | 1629 |
Native libraries and executables can have debug symbol (and other debug |
1630 |
information) associated with them. How this works is very much platform |
|
1631 |
dependent, but a common problem is that debug symbol information takes a lot of |
|
1632 |
disk space, but is rarely needed by the end user. |
|
33030 | 1633 |
|
45763 | 1634 |
The OpenJDK supports different methods on how to handle debug symbols. The |
1635 |
method used is selected by `--with-native-debug-symbols`, and available methods |
|
1636 |
are `none`, `internal`, `external`, `zipped`. |
|
33030 | 1637 |
|
45763 | 1638 |
* `none` means that no debug symbols will be generated during the build. |
1639 |
||
1640 |
* `internal` means that debug symbols will be generated during the build, and |
|
1641 |
they will be stored in the generated binary. |
|
33030 | 1642 |
|
45763 | 1643 |
* `external` means that debug symbols will be generated during the build, and |
1644 |
after the compilation, they will be moved into a separate `.debuginfo` file. |
|
1645 |
(This was previously known as FDS, Full Debug Symbols). |
|
1646 |
||
1647 |
* `zipped` is like `external`, but the .debuginfo file will also be zipped |
|
1648 |
into a `.diz` file. |
|
33030 | 1649 |
|
45763 | 1650 |
When building for distribution, `zipped` is a good solution. Binaries built |
1651 |
with `internal` is suitable for use by developers, since they facilitate |
|
1652 |
debugging, but should be stripped before distributed to end users. |
|
33030 | 1653 |
|
45763 | 1654 |
### Autoconf Details |
1655 |
||
1656 |
The `configure` script is based on the autoconf framework, but in some details |
|
1657 |
deviate from a normal autoconf `configure` script. |
|
33030 | 1658 |
|
45763 | 1659 |
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
|
1660 |
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
|
1661 |
to create the runnable (generated) configure script, as |
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1662 |
`.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
|
1663 |
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
|
1664 |
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
|
1665 |
part of this functionality, the generated script is called. |
33030 | 1666 |
|
45763 | 1667 |
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
|
1668 |
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
|
1669 |
manually request such an update by `bash configure autogen`. |
33030 | 1670 |
|
48743
ba52fa7bbf14
8195689: Remove generated-configure.sh and instead use autoconf
ihse
parents:
47928
diff
changeset
|
1671 |
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
|
1672 |
`make/autoconf/generated-configure.sh`. This is no longer the case. |
33030 | 1673 |
|
45763 | 1674 |
### Developing the Build System Itself |
33030 | 1675 |
|
45763 | 1676 |
This section contains a few remarks about how to develop for the build system |
1677 |
itself. It is not relevant if you are only making changes in the product source |
|
1678 |
code. |
|
33030 | 1679 |
|
45763 | 1680 |
While technically using `make`, the make source files of the OpenJDK does not |
1681 |
resemble most other Makefiles. Instead of listing specific targets and actions |
|
1682 |
(perhaps using patterns), the basic modus operandi is to call a high-level |
|
1683 |
function (or properly, macro) from the API in `make/common`. For instance, to |
|
1684 |
compile all classes in the `jdk.internal.foo` package in the `jdk.foo` module, |
|
1685 |
a call like this would be made: |
|
33030 | 1686 |
|
45763 | 1687 |
``` |
1688 |
$(eval $(call SetupJavaCompilation, BUILD_FOO_CLASSES, \ |
|
1689 |
SETUP := GENERATE_OLDBYTECODE, \ |
|
47219 | 1690 |
SRC := $(TOPDIR)/src/jkd.foo/share/classes, \ |
45763 | 1691 |
INCLUDES := jdk/internal/foo, \ |
1692 |
BIN := $(SUPPORT_OUTPUTDIR)/foo_classes, \ |
|
1693 |
)) |
|
1694 |
``` |
|
33030 | 1695 |
|
45763 | 1696 |
By encapsulating and expressing the high-level knowledge of *what* should be |
1697 |
done, rather than *how* it should be done (as is normal in Makefiles), we can |
|
1698 |
build a much more powerful and flexible build system. |
|
1699 |
||
1700 |
Correct dependency tracking is paramount. Sloppy dependency tracking will lead |
|
1701 |
to improper parallelization, or worse, race conditions. |
|
33030 | 1702 |
|
45763 | 1703 |
To test for/debug race conditions, try running `make JOBS=1` and `make |
1704 |
JOBS=100` and see if it makes any difference. (It shouldn't). |
|
1705 |
||
1706 |
To compare the output of two different builds and see if, and how, they differ, |
|
1707 |
run `$BUILD1/compare.sh -o $BUILD2`, where `$BUILD1` and `$BUILD2` are the two |
|
1708 |
builds you want to compare. |
|
33030 | 1709 |
|
45763 | 1710 |
To automatically build two consecutive versions and compare them, use |
1711 |
`COMPARE_BUILD`. The value of `COMPARE_BUILD` is a set of variable=value |
|
1712 |
assignments, like this: |
|
1713 |
``` |
|
1714 |
make COMPARE_BUILD=CONF=--enable-new-hotspot-feature:MAKE=hotspot |
|
1715 |
``` |
|
1716 |
See `make/InitSupport.gmk` for details on how to use `COMPARE_BUILD`. |
|
33030 | 1717 |
|
45763 | 1718 |
To analyze build performance, run with `LOG=trace` and check `$BUILD/build-trace-time.log`. |
1719 |
Use `JOBS=1` to avoid parallelism. |
|
33030 | 1720 |
|
45763 | 1721 |
Please check that you adhere to the [Code Conventions for the Build System]( |
1722 |
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
|
1723 |
submitting patches. |
45763 | 1724 |
|
1725 |
## Contributing to OpenJDK |
|
1726 |
||
1727 |
So, now you've build your OpenJDK, and made your first patch, and want to |
|
1728 |
contribute it back to the OpenJDK community. |
|
33030 | 1729 |
|
45763 | 1730 |
First of all: Thank you! We gladly welcome your contribution to the OpenJDK. |
1731 |
However, please bear in mind that OpenJDK is a massive project, and we must ask |
|
1732 |
you to follow our rules and guidelines to be able to accept your contribution. |
|
33030 | 1733 |
|
45763 | 1734 |
The official place to start is the ['How to contribute' page]( |
1735 |
http://openjdk.java.net/contribute/). There is also an official (but somewhat |
|
1736 |
outdated and skimpy on details) [Developer's Guide]( |
|
1737 |
http://openjdk.java.net/guide/). |
|
33030 | 1738 |
|
45763 | 1739 |
If this seems overwhelming to you, the Adoption Group is there to help you! A |
1740 |
good place to start is their ['New Contributor' page]( |
|
1741 |
https://wiki.openjdk.java.net/display/Adoption/New+Contributor), or start |
|
1742 |
reading the comprehensive [Getting Started Kit]( |
|
1743 |
https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting-started-kit/en/). The |
|
1744 |
Adoption Group will also happily answer any questions you have about |
|
1745 |
contributing. Contact them by [mail]( |
|
1746 |
http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss) or [IRC]( |
|
1747 |
http://openjdk.java.net/irc/). |
|
33030 | 1748 |
|
45763 | 1749 |
--- |
1750 |
# Override styles from the base CSS file that are not ideal for this document. |
|
1751 |
header-includes: |
|
1752 |
- '<style type="text/css">pre, code, tt { color: #1d6ae5; }</style>' |
|
1753 |
--- |