forked from corretto/corretto-8
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README-builds.html
1389 lines (1094 loc) · 57.7 KB
/
README-builds.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html>
<head>
<title>OpenJDK Build README</title>
</head>
<body>
<p><img src="http://openjdk.java.net/images/openjdk.png" alt="OpenJDK" title="" /></p>
<h1>OpenJDK Build README</h1>
<hr />
<p><a name="introduction"></a></p>
<h2>Introduction</h2>
<p>This README file contains build instructions for the
<a href="http://openjdk.java.net">OpenJDK</a>. Building the source code for the OpenJDK
requires a certain degree of technical expertise.</p>
<h3>!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!</h3>
<p>Some Headlines:</p>
<ul>
<li>The build is now a "<code>configure && make</code>" style build</li>
<li>Any GNU make 3.81 or newer should work</li>
<li>The build should scale, i.e. more processors should cause the build to be
done in less wall-clock time</li>
<li>Nested or recursive make invocations have been significantly reduced,
as has the total fork/exec or spawning of sub processes during the build</li>
<li>Windows MKS usage is no longer supported</li>
<li>Windows Visual Studio <code>vsvars*.bat</code> and <code>vcvars*.bat</code> files are run
automatically</li>
<li>Ant is no longer used when building the OpenJDK</li>
<li>Use of ALT_* environment variables for configuring the build is no longer
supported</li>
</ul>
<hr />
<h2>Contents</h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#hg">Use of Mercurial</a>
<ul>
<li><a href="#get_source">Getting the Source</a></li>
<li><a href="#repositories">Repositories</a></li>
</ul></li>
<li><a href="#building">Building</a>
<ul>
<li><a href="#setup">System Setup</a>
<ul>
<li><a href="#linux">Linux</a></li>
<li><a href="#solaris">Solaris</a></li>
<li><a href="#macosx">Mac OS X</a></li>
<li><a href="#windows">Windows</a></li>
</ul></li>
<li><a href="#configure">Configure</a></li>
<li><a href="#make">Make</a></li>
</ul></li>
<li><a href="#testing">Testing</a></li>
</ul>
<hr />
<ul>
<li><a href="#hints">Appendix A: Hints and Tips</a>
<ul>
<li><a href="#faq">FAQ</a></li>
<li><a href="#performance">Build Performance Tips</a></li>
<li><a href="#troubleshooting">Troubleshooting</a></li>
</ul></li>
<li><a href="#gmake">Appendix B: GNU Make Information</a></li>
<li><a href="#buildenvironments">Appendix C: Build Environments</a></li>
</ul>
<hr />
<p><a name="hg"></a></p>
<h2>Use of Mercurial</h2>
<p>The OpenJDK sources are maintained with the revision control system
<a href="http://mercurial.selenic.com/wiki/Mercurial">Mercurial</a>. If you are new to
Mercurial, please see the <a href="http://mercurial.selenic.com/wiki/
BeginnersGuides">Beginner Guides</a> or refer to the <a href="http://hgbook.red-bean.com/">Mercurial Book</a>.
The first few chapters of the book provide an excellent overview of Mercurial,
what it is and how it works.</p>
<p>For using Mercurial with the OpenJDK refer to the <a href="http://openjdk.java.net/guide/
repositories.html#installConfig">Developer Guide: Installing
and Configuring Mercurial</a> section for more information.</p>
<p><a name="get_source"></a></p>
<h3>Getting the Source</h3>
<p>To get the entire set of OpenJDK Mercurial repositories use the script
<code>get_source.sh</code> located in the root repository:</p>
<pre><code> hg clone http://hg.openjdk.java.net/jdk8/jdk8 YourOpenJDK
cd YourOpenJDK
bash ./get_source.sh
</code></pre>
<p>Once you have all the repositories, keep in mind that each repository is its
own independent repository. You can also re-run <code>./get_source.sh</code> anytime to
pull over all the latest changesets in all the repositories. This set of
nested repositories has been given the term "forest" and there are various
ways to apply the same <code>hg</code> command to each of the repositories. For
example, the script <code>make/scripts/hgforest.sh</code> can be used to repeat the
same <code>hg</code> command on every repository, e.g.</p>
<pre><code> cd YourOpenJDK
bash ./make/scripts/hgforest.sh status
</code></pre>
<p><a name="repositories"></a></p>
<h3>Repositories</h3>
<p>The set of repositories and what they contain:</p>
<ul>
<li><strong>. (root)</strong> contains common configure and makefile logic</li>
<li><strong>hotspot</strong> contains source code and make files for building the OpenJDK
Hotspot Virtual Machine</li>
<li><strong>langtools</strong> contains source code for the OpenJDK javac and language tools</li>
<li><strong>jdk</strong> contains source code and make files for building the OpenJDK runtime
libraries and misc files</li>
<li><strong>jaxp</strong> contains source code for the OpenJDK JAXP functionality</li>
<li><strong>jaxws</strong> contains source code for the OpenJDK JAX-WS functionality</li>
<li><strong>corba</strong> contains source code for the OpenJDK Corba functionality</li>
<li><strong>nashorn</strong> contains source code for the OpenJDK JavaScript implementation</li>
</ul>
<h3>Repository Source Guidelines</h3>
<p>There are some very basic guidelines:</p>
<ul>
<li>Use of whitespace in source files (.java, .c, .h, .cpp, and .hpp files) is
restricted. No TABs, no trailing whitespace on lines, and files should not
terminate in more than one blank line.</li>
<li>Files with execute permissions should not be added to the source
repositories.</li>
<li>All generated files need to be kept isolated from the files maintained or
managed by the source control system. The standard area for generated files
is the top level <code>build/</code> directory.</li>
<li>The default build process should be to build the product and nothing else,
in one form, e.g. a product (optimized), debug (non-optimized, -g plus
assert logic), or fastdebug (optimized, -g plus assert logic).</li>
<li>The <code>.hgignore</code> file in each repository must exist and should include
<code>^build/</code>, <code>^dist/</code> and optionally any <code>nbproject/private</code> directories. <strong>It
should NEVER</strong> include anything in the <code>src/</code> or <code>test/</code> or any managed
directory area of a repository.</li>
<li>Directory names and file names should never contain blanks or non-printing
characters.</li>
<li>Generated source or binary files should NEVER be added to the repository
(that includes <code>javah</code> output). There are some exceptions to this rule, in
particular with some of the generated configure scripts.</li>
<li>Files not needed for typical building or testing of the repository should
not be added to the repository.</li>
</ul>
<hr />
<p><a name="building"></a></p>
<h2>Building</h2>
<p>The very first step in building the OpenJDK is making sure the system itself
has everything it needs to do OpenJDK builds. Once a system is setup, it
generally doesn't need to be done again.</p>
<p>Building the OpenJDK is now done with running a <code>configure</code> script which will
try and find and verify you have everything you need, followed by running
<code>make</code>, e.g.</p>
<blockquote>
<p><strong><code>bash ./configure</code></strong> <br />
<strong><code>make all</code></strong></p>
</blockquote>
<p>Where possible the <code>configure</code> script will attempt to located the various
components in the default locations or via component specific variable
settings. When the normal defaults fail or components cannot be found,
additional <code>configure</code> options may be necessary to help <code>configure</code> find the
necessary tools for the build, or you may need to re-visit the setup of your
system due to missing software packages.</p>
<p><strong>NOTE:</strong> The <code>configure</code> script file does not have execute permissions and
will need to be explicitly run with <code>bash</code>, see the source guidelines.</p>
<hr />
<p><a name="setup"></a></p>
<h3>System Setup</h3>
<p>Before even attempting to use a system to build the OpenJDK there are some very
basic system setups needed. For all systems:</p>
<ul>
<li><p>Be sure the GNU make utility is version 3.81 or newer, e.g.
run "<code>make -version</code>"</p>
<p><a name="bootjdk"></a></p></li>
<li><p>Install a Bootstrap JDK. All OpenJDK builds require access to a previously
released JDK called the <em>bootstrap JDK</em> or <em>boot JDK.</em> The general rule is
that the bootstrap JDK must be an instance of the previous major release of
the JDK. In addition, there may be a requirement to use a release at or
beyond a particular update level.</p>
<p><strong><em>Building JDK 8 requires use of a version of JDK 7 this is at Update 7
or newer. JDK 8 developers should not use JDK 8 as the boot JDK, to ensure
that JDK 8 dependencies are not introduced into the parts of the system
that are built with JDK 7.</em></strong></p>
<p>The JDK 7 binaries can be downloaded from Oracle's <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html">JDK 7 download
site</a>.
For build performance reasons it is very important that this bootstrap JDK
be made available on the local disk of the machine doing the build. You
should add its <code>bin</code> directory to the <code>PATH</code> environment variable. If
<code>configure</code> has any issues finding this JDK, you may need to use the
<code>configure</code> option <code>--with-boot-jdk</code>.</p></li>
<li><p>Ensure that GNU make, the Bootstrap JDK, and the compilers are all in your
PATH environment variable.</p></li>
</ul>
<p>And for specific systems:</p>
<ul>
<li><p><strong>Linux</strong></p>
<p>Install all the software development packages needed including
<a href="#alsa">alsa</a>, <a href="#freetype">freetype</a>, <a href="#cups">cups</a>, and
<a href="#xrender">xrender</a>. See <a href="#SDBE">specific system packages</a>.</p></li>
<li><p><strong>Solaris</strong></p>
<p>Install all the software development packages needed including <a href="#studio">Studio
Compilers</a>, <a href="#freetype">freetype</a>, <a href="#cups">cups</a>, and
<a href="#xrender">xrender</a>. See <a href="#SDBE">specific system packages</a>.</p></li>
<li><p><strong>Windows</strong></p>
<ul>
<li>Install one of <a href="#cygwin">CYGWIN</a> or <a href="#msys">MinGW/MSYS</a></li>
<li>Install <a href="#vs2010">Visual Studio 2010</a></li>
</ul></li>
<li><p><strong>Mac OS X</strong></p>
<p>Install <a href="https://developer.apple.com/xcode/">XCode 4.5.2</a> and also
install the "Command line tools" found under the preferences pane
"Downloads"</p></li>
</ul>
<p><a name="linux"></a></p>
<h4>Linux</h4>
<p>With Linux, try and favor the system packages over building your own or getting
packages from other areas. Most Linux builds should be possible with the
system's available packages.</p>
<p>Note that some Linux systems have a habit of pre-populating your environment
variables for you, for example <code>JAVA_HOME</code> might get pre-defined for you to
refer to the JDK installed on your Linux system. You will need to unset
<code>JAVA_HOME</code>. It's a good idea to run <code>env</code> and verify the environment variables
you are getting from the default system settings make sense for building the
OpenJDK.</p>
<p><a name="solaris"></a></p>
<h4>Solaris</h4>
<p><a name="studio"></a></p>
<h5>Studio Compilers</h5>
<p>At a minimum, the <a href="http://www.oracle.com/
technetwork/server-storage/solarisstudio/downloads/index.htm">Studio 12 Update 1 Compilers</a> (containing
version 5.10 of the C and C++ compilers) is required, including specific
patches.</p>
<p>The Solaris SPARC patch list is:</p>
<ul>
<li>118683-05: SunOS 5.10: Patch for profiling libraries and assembler</li>
<li>119963-21: SunOS 5.10: Shared library patch for C++</li>
<li>120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch</li>
<li>128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler</li>
<li>141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C
C++ F77 F95</li>
<li>141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler</li>
<li>142371-01: Sun Studio 12.1 Update 1: Patch for dbx</li>
<li>143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling</li>
<li>143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C
C++ F77 F95</li>
<li>142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools</li>
</ul>
<p>The Solaris X86 patch list is:</p>
<ul>
<li>119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler</li>
<li>119964-21: SunOS 5.10_x86: Shared library patch for C++_x86</li>
<li>120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch</li>
<li>141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86
backend</li>
<li>128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler</li>
<li>142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler</li>
<li>142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools</li>
</ul>
<p>Place the <code>bin</code> directory in <code>PATH</code>.</p>
<p>The Oracle Solaris Studio Express compilers at: <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/
downloads/index-jsp-142582.html">Oracle Solaris Studio Express
Download site</a> are also an option, although these compilers
have not been extensively used yet.</p>
<p><a name="windows"></a></p>
<h4>Windows</h4>
<h5>Windows Unix Toolkit</h5>
<p>Building on Windows requires a Unix-like environment, notably a Unix-like
shell. There are several such environments available of which
<a href="http://www.cygwin.com/">Cygwin</a> and
<a href="http://www.mingw.org/wiki/MSYS">MinGW/MSYS</a> are currently supported for the
OpenJDK build. One of the differences of these systems from standard Windows
tools is the way they handle Windows path names, particularly path names which
contain spaces, backslashes as path separators and possibly drive letters.
Depending on the use case and the specifics of each environment these path
problems can be solved by a combination of quoting whole paths, translating
backslashes to forward slashes, escaping backslashes with additional
backslashes and translating the path names to their <a href="http://en.wikipedia.org/wiki/8.3_filename">"8.3"
version</a>.</p>
<p><a name="cygwin"></a></p>
<h6>CYGWIN</h6>
<p>CYGWIN is an open source, Linux-like environment which tries to emulate a
complete POSIX layer on Windows. It tries to be smart about path names and can
usually handle all kinds of paths if they are correctly quoted or escaped
although internally it maps drive letters <code><drive>:</code> to a virtual directory
<code>/cygdrive/<drive></code>.</p>
<p>You can always use the <code>cygpath</code> utility to map pathnames with spaces or the
backslash character into the <code>C:/</code> style of pathname (called 'mixed'), e.g.
<code>cygpath -s -m "<path>"</code>.</p>
<p>Note that the use of CYGWIN creates a unique problem with regards to setting
<a href="#path"><code>PATH</code></a>. Normally on Windows the <code>PATH</code> variable contains directories
separated with the ";" character (Solaris and Linux use ":"). With CYGWIN, it
uses ":", but that means that paths like "C:/path" cannot be placed in the
CYGWIN version of <code>PATH</code> and instead CYGWIN uses something like
<code>/cygdrive/c/path</code> which CYGWIN understands, but only CYGWIN understands.</p>
<p>The OpenJDK build requires CYGWIN version 1.7.16 or newer. Information about
CYGWIN can be obtained from the CYGWIN website at
<a href="http://www.cygwin.com">www.cygwin.com</a>.</p>
<p>By default CYGWIN doesn't install all the tools required for building the
OpenJDK. Along with the default installation, you need to install the following
tools.</p>
<blockquote>
<p><table border="1">
<thead>
<tr>
<td>Binary Name</td>
<td>Category</td>
<td>Package</td>
<td>Description</td>
</tr>
</thead>
<tbody>
<tr>
<td>ar.exe</td>
<td>Devel</td>
<td>binutils</td>
<td>The GNU assembler, linker and binary utilities</td>
</tr>
<tr>
<td>make.exe</td>
<td>Devel</td>
<td>make</td>
<td>The GNU version of the 'make' utility built for CYGWIN</td>
</tr>
<tr>
<td>m4.exe</td>
<td>Interpreters</td>
<td>m4</td>
<td>GNU implementation of the traditional Unix macro processor</td>
</tr>
<tr>
<td>cpio.exe</td>
<td>Utils</td>
<td>cpio</td>
<td>A program to manage archives of files</td>
</tr>
<tr>
<td>gawk.exe</td>
<td>Utils</td>
<td>awk</td>
<td>Pattern-directed scanning and processing language</td>
</tr>
<tr>
<td>file.exe</td>
<td>Utils</td>
<td>file</td>
<td>Determines file type using 'magic' numbers</td>
</tr>
<tr>
<td>zip.exe</td>
<td>Archive</td>
<td>zip</td>
<td>Package and compress (archive) files</td>
</tr>
<tr>
<td>unzip.exe</td>
<td>Archive</td>
<td>unzip</td>
<td>Extract compressed files in a ZIP archive</td>
</tr>
<tr>
<td>free.exe</td>
<td>System</td>
<td>procps</td>
<td>Display amount of free and used memory in the system</td>
</tr>
</tbody>
</table></p>
</blockquote>
<p>Note that the CYGWIN software can conflict with other non-CYGWIN software on
your Windows system. CYGWIN provides a <a href="http://cygwin.com/faq/
faq.using.html">FAQ</a> for known issues and problems, of particular interest is the
section on <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda">BLODA (applications that interfere with
CYGWIN)</a>.</p>
<p><a name="msys"></a></p>
<h6>MinGW/MSYS</h6>
<p>MinGW ("Minimalist GNU for Windows") is a collection of free Windows specific
header files and import libraries combined with GNU toolsets that allow one to
produce native Windows programs that do not rely on any 3rd-party C runtime
DLLs. MSYS is a supplement to MinGW which allows building applications and
programs which rely on traditional UNIX tools to be present. Among others this
includes tools like <code>bash</code> and <code>make</code>. See <a href="http://www.mingw.org/
wiki/MSYS">MinGW/MSYS</a> for more information.</p>
<p>Like Cygwin, MinGW/MSYS can handle different types of path formats. They are
internally converted to paths with forward slashes and drive letters
<code><drive>:</code> replaced by a virtual directory <code>/<drive></code>. Additionally, MSYS
automatically detects binaries compiled for the MSYS environment and feeds them
with the internal, Unix-style path names. If native Windows applications are
called from within MSYS programs their path arguments are automatically
converted back to Windows style path names with drive letters and backslashes
as path separators. This may cause problems for Windows applications which use
forward slashes as parameter separator (e.g. <code>cl /nologo /I</code>) because MSYS may
wrongly <a href="http://mingw.org/wiki/
Posix_path_conversion">replace such parameters by drive letters</a>.</p>
<p>In addition to the tools which will be installed by default, you have to
manually install the <code>msys-zip</code> and <code>msys-unzip</code> packages. This can be easily
done with the MinGW command line installer:</p>
<pre><code> mingw-get.exe install msys-zip
mingw-get.exe install msys-unzip
</code></pre>
<p><a name="vs2010"></a></p>
<h5>Visual Studio 2010 Compilers</h5>
<p>The 32-bit and 64-bit OpenJDK Windows build requires Microsoft Visual Studio
C++ 2010 (VS2010) Professional Edition or Express compiler. The compiler and
other tools are expected to reside in the location defined by the variable
<code>VS100COMNTOOLS</code> which is set by the Microsoft Visual Studio installer.</p>
<p>Only the C++ part of VS2010 is needed. Try to let the installation go to the
default install directory. Always reboot your system after installing VS2010.
The system environment variable VS100COMNTOOLS should be set in your
environment.</p>
<p>Make sure that TMP and TEMP are also set in the environment and refer to
Windows paths that exist, like <code>C:\temp</code>, not <code>/tmp</code>, not <code>/cygdrive/c/temp</code>,
and not <code>C:/temp</code>. <code>C:\temp</code> is just an example, it is assumed that this area
is private to the user, so by default after installs you should see a unique
user path in these variables.</p>
<p><a name="macosx"></a></p>
<h4>Mac OS X</h4>
<p>Make sure you get the right XCode version.</p>
<hr />
<p><a name="configure"></a></p>
<h3>Configure</h3>
<p>The basic invocation of the <code>configure</code> script looks like:</p>
<blockquote>
<p><strong><code>bash ./configure [options]</code></strong></p>
</blockquote>
<p>This will create an output directory containing the "configuration" and setup
an area for the build result. This directory typically looks like:</p>
<blockquote>
<p><strong><code>build/linux-x64-normal-server-release</code></strong></p>
</blockquote>
<p><code>configure</code> will try to figure out what system you are running on and where all
necessary build components are. If you have all prerequisites for building
installed, it should find everything. If it fails to detect any component
automatically, it will exit and inform you about the problem. When this
happens, read more below in <a href="#configureoptions">the <code>configure</code> options</a>.</p>
<p>Some examples:</p>
<blockquote>
<p><strong>Windows 32bit build with freetype specified:</strong> <br />
<code>bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-
bits=32</code></p>
<p><strong>Debug 64bit Build:</strong> <br />
<code>bash ./configure --enable-debug --with-target-bits=64</code></p>
</blockquote>
<p><a name="configureoptions"></a></p>
<h4>Configure Options</h4>
<p>Complete details on all the OpenJDK <code>configure</code> options can be seen with:</p>
<blockquote>
<p><strong><code>bash ./configure --help=short</code></strong></p>
</blockquote>
<p>Use <code>-help</code> to see all the <code>configure</code> options available. You can generate any
number of different configurations, e.g. debug, release, 32, 64, etc.</p>
<p>Some of the more commonly used <code>configure</code> options are:</p>
<blockquote>
<p><strong><code>--enable-debug</code></strong> <br />
set the debug level to fastdebug (this is a shorthand for <code>--with-debug-
level=fastdebug</code>)</p>
</blockquote>
<p><a name="alsa"></a></p>
<blockquote>
<p><strong><code>--with-alsa=</code></strong><em>path</em> <br />
select the location of the Advanced Linux Sound Architecture (ALSA)</p>
<p>Version 0.9.1 or newer of the ALSA files are required for building the
OpenJDK on Linux. These Linux files are usually available from an "alsa" of
"libasound" development package, and it's highly recommended that you try
and use the package provided by the particular version of Linux that you are
using.</p>
<p><strong><code>--with-boot-jdk=</code></strong><em>path</em> <br />
select the <a href="#bootjdk">Bootstrap JDK</a></p>
<p><strong><code>--with-boot-jdk-jvmargs=</code></strong>"<em>args</em>" <br />
provide the JVM options to be used to run the <a href="#bootjdk">Bootstrap JDK</a></p>
<p><strong><code>--with-cacerts=</code></strong><em>path</em> <br />
select the path to the cacerts file.</p>
<p>See <a href="http://en.wikipedia.org/wiki/
Certificate_Authority">Certificate Authority on Wikipedia</a> for a better understanding of the Certificate
Authority (CA). A certificates file named "cacerts" represents a system-wide
keystore with CA certificates. In JDK and JRE binary bundles, the "cacerts"
file contains root CA certificates from several public CAs (e.g., VeriSign,
Thawte, and Baltimore). The source contain a cacerts file without CA root
certificates. Formal JDK builders will need to secure permission from each
public CA and include the certificates into their own custom cacerts file.
Failure to provide a populated cacerts file will result in verification
errors of a certificate chain during runtime. By default an empty cacerts
file is provided and that should be fine for most JDK developers.</p>
</blockquote>
<p><a name="cups"></a></p>
<blockquote>
<p><strong><code>--with-cups=</code></strong><em>path</em> <br />
select the CUPS install location</p>
<p>The Common UNIX Printing System (CUPS) Headers are required for building the
OpenJDK on Solaris and Linux. The Solaris header files can be obtained by
installing the package <strong>SFWcups</strong> from the Solaris Software Companion
CD/DVD, these often will be installed into the directory <code>/opt/sfw/cups</code>.</p>
<p>The CUPS header files can always be downloaded from
<a href="http://www.cups.org">www.cups.org</a>.</p>
<p><strong><code>--with-cups-include=</code></strong><em>path</em> <br />
select the CUPS include directory location</p>
<p><strong><code>--with-debug-level=</code></strong><em>level</em> <br />
select the debug information level of release, fastdebug, or slowdebug</p>
<p><strong><code>--with-dev-kit=</code></strong><em>path</em> <br />
select location of the compiler install or developer install location</p>
</blockquote>
<p><a name="freetype"></a></p>
<blockquote>
<p><strong><code>--with-freetype=</code></strong><em>path</em> <br />
select the freetype files to use.</p>
<p>Expecting the freetype libraries under <code>lib/</code> and the headers under
<code>include/</code>.</p>
<p>Version 2.3 or newer of FreeType is required. On Unix systems required files
can be available as part of your distribution (while you still may need to
upgrade them). Note that you need development version of package that
includes both the FreeType library and header files.</p>
<p>You can always download latest FreeType version from the <a href="http://www.freetype.org">FreeType
website</a>. Building the freetype 2 libraries from
scratch is also possible, however on Windows refer to the <a href="http://freetype.freedesktop.org/wiki/FreeType_DLL">Windows FreeType
DLL build instructions</a>.</p>
<p>Note that by default FreeType is built with byte code hinting support
disabled due to licensing restrictions. In this case, text appearance and
metrics are expected to differ from Sun's official JDK build. See the
<a href="http://freetype.sourceforge.net/freetype2">SourceForge FreeType2 Home Page</a>
for more information.</p>
<p><strong><code>--with-import-hotspot=</code></strong><em>path</em> <br />
select the location to find hotspot binaries from a previous build to avoid
building hotspot</p>
<p><strong><code>--with-target-bits=</code></strong><em>arg</em> <br />
select 32 or 64 bit build</p>
<p><strong><code>--with-jvm-variants=</code></strong><em>variants</em> <br />
select the JVM variants to build from, comma separated list that can
include: server, client, kernel, zero and zeroshark</p>
<p><strong><code>--with-memory-size=</code></strong><em>size</em> <br />
select the RAM size that GNU make will think this system has</p>
<p><strong><code>--with-msvcr-dll=</code></strong><em>path</em> <br />
select the <code>msvcr100.dll</code> file to include in the Windows builds (C/C++
runtime library for Visual Studio).</p>
<p>This is usually picked up automatically from the redist directories of
Visual Studio 2010.</p>
<p><strong><code>--with-num-cores=</code></strong><em>cores</em> <br />
select the number of cores to use (processor count or CPU count)</p>
</blockquote>
<p><a name="xrender"></a></p>
<blockquote>
<p><strong><code>--with-x=</code></strong><em>path</em> <br />
select the location of the X11 and xrender files.</p>
<p>The XRender Extension Headers are required for building the OpenJDK on
Solaris and Linux. The Linux header files are usually available from a
"Xrender" development package, it's recommended that you try and use the
package provided by the particular distribution of Linux that you are using.
The Solaris XRender header files is included with the other X11 header files
in the package <strong>SFWxwinc</strong> on new enough versions of Solaris and will be
installed in <code>/usr/X11/include/X11/extensions/Xrender.h</code> or
<code>/usr/openwin/share/include/X11/extensions/Xrender.h</code></p>
</blockquote>
<hr />
<p><a name="make"></a></p>
<h3>Make</h3>
<p>The basic invocation of the <code>make</code> utility looks like:</p>
<blockquote>
<p><strong><code>make all</code></strong></p>
</blockquote>
<p>This will start the build to the output directory containing the
"configuration" that was created by the <code>configure</code> script. Run <code>make help</code> for
more information on the available targets.</p>
<p>There are some of the make targets that are of general interest:</p>
<blockquote>
<p><em>empty</em> <br />
build everything but no images</p>
<p><strong><code>all</code></strong> <br />
build everything including images</p>
<p><strong><code>all-conf</code></strong> <br />
build all configurations</p>
<p><strong><code>images</code></strong> <br />
create complete j2sdk and j2re images</p>
<p><strong><code>install</code></strong> <br />
install the generated images locally, typically in <code>/usr/local</code></p>
<p><strong><code>clean</code></strong> <br />
remove all files generated by make, but not those generated by <code>configure</code></p>
<p><strong><code>dist-clean</code></strong> <br />
remove all files generated by both and <code>configure</code> (basically killing the
configuration)</p>
<p><strong><code>help</code></strong> <br />
give some help on using <code>make</code>, including some interesting make targets</p>
</blockquote>
<hr />
<p><a name="testing"></a></p>
<h2>Testing</h2>
<p>When the build is completed, you should see the generated binaries and
associated files in the <code>j2sdk-image</code> directory in the output directory. In
particular, the <code>build/*/images/j2sdk-image/bin</code> directory should contain
executables for the OpenJDK tools and utilities for that configuration. The
testing tool <code>jtreg</code> will be needed and can be found at: <a href="http://openjdk.java.net/jtreg/">the jtreg
site</a>. The provided regression tests in the
repositories can be run with the command:</p>
<blockquote>
<p><strong><code>cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all</code></strong></p>
</blockquote>
<hr />
<p><a name="hints"></a></p>
<h2>Appendix A: Hints and Tips</h2>
<p><a name="faq"></a></p>
<h3>FAQ</h3>
<p><strong>Q:</strong> The <code>generated-configure.sh</code> file looks horrible! How are you going to
edit it? <br />
<strong>A:</strong> The <code>generated-configure.sh</code> file is generated (think "compiled") by the
autoconf tools. The source code is in <code>configure.ac</code> and various .m4 files in
common/autoconf, which are much more readable.</p>
<p><strong>Q:</strong> Why is the <code>generated-configure.sh</code> file checked in, if it is
generated? <br />
<strong>A:</strong> If it was not generated, every user would need to have the autoconf
tools installed, and re-generate the <code>configure</code> file as the first step. Our
goal is to minimize the work needed to be done by the user to start building
OpenJDK, and to minimize the number of external dependencies required.</p>
<p><strong>Q:</strong> Do you require a specific version of autoconf for regenerating
<code>generated-configure.sh</code>? <br />
<strong>A:</strong> Yes, version 2.69 is required and should be easy enough to aquire on all
supported operating systems. The reason for this is to avoid large spurious
changes in <code>generated-configure.sh</code>.</p>
<p><strong>Q:</strong> How do you regenerate <code>generated-configure.sh</code> after making changes to
the input files? <br />
<strong>A:</strong> Regnerating <code>generated-configure.sh</code> should always be done using the
script <code>common/autoconf/autogen.sh</code> to ensure that the correct files get
updated. This script should also be run after mercurial tries to merge
<code>generated-configure.sh</code> as a merge of the generated file is not guaranteed to
be correct.</p>
<p><strong>Q:</strong> What are the files in <code>common/makefiles/support/*</code> for? They look like
gibberish. <br />
<strong>A:</strong> They are a somewhat ugly hack to compensate for command line length
limitations on certain platforms (Windows, Solaris). Due to a combination of
limitations in make and the shell, command lines containing too many files will
not work properly. These helper files are part of an elaborate hack that will
compress the command line in the makefile and then uncompress it safely. We're
not proud of it, but it does fix the problem. If you have any better
suggestions, we're all ears! :-)</p>
<p><strong>Q:</strong> I want to see the output of the commands that make runs, like in the old
build. How do I do that? <br />
<strong>A:</strong> You specify the <code>LOG</code> variable to make. There are several log levels:</p>
<ul>
<li><strong><code>warn</code></strong> -- Default and very quiet.</li>
<li><strong><code>info</code></strong> -- Shows more progress information than warn.</li>
<li><strong><code>debug</code></strong> -- Echos all command lines and prints all macro calls for
compilation definitions.</li>
<li><strong><code>trace</code></strong> -- Echos all $(shell) command lines as well.</li>
</ul>
<p><strong>Q:</strong> When do I have to re-run <code>configure</code>? <br />
<strong>A:</strong> Normally you will run <code>configure</code> only once for creating a
configuration. You need to re-run configuration only if you want to change any
configuration options, or if you pull down changes to the <code>configure</code> script.</p>
<p><strong>Q:</strong> I have added a new source file. Do I need to modify the makefiles? <br />
<strong>A:</strong> Normally, no. If you want to create e.g. a new native library, you will
need to modify the makefiles. But for normal file additions or removals, no
changes are needed. There are certan exceptions for some native libraries where
the source files are spread over many directories which also contain sources
for other libraries. In these cases it was simply easier to create include
lists rather than excludes.</p>
<p><strong>Q:</strong> When I run <code>configure --help</code>, I see many strange options, like
<code>--dvidir</code>. What is this? <br />
<strong>A:</strong> Configure provides a slew of options by default, to all projects that
use autoconf. Most of them are not used in OpenJDK, so you can safely ignore
them. To list only OpenJDK specific features, use <code>configure --help=short</code>
instead.</p>
<p><strong>Q:</strong> <code>configure</code> provides OpenJDK-specific features such as <code>--with-
builddeps-server</code> that are not described in this document. What about those? <br />
<strong>A:</strong> Try them out if you like! But be aware that most of these are
experimental features. Many of them don't do anything at all at the moment; the
option is just a placeholder. Others depend on pieces of code or infrastructure
that is currently not ready for prime time.</p>
<p><strong>Q:</strong> How will you make sure you don't break anything? <br />
<strong>A:</strong> We have a script that compares the result of the new build system with
the result of the old. For most part, we aim for (and achieve) byte-by-byte
identical output. There are however technical issues with e.g. native binaries,
which might differ in a byte-by-byte comparison, even when building twice with
the old build system. For these, we compare relevant aspects (e.g. the symbol
table and file size). Note that we still don't have 100% equivalence, but we're
close.</p>
<p><strong>Q:</strong> I noticed this thing X in the build that looks very broken by design.
Why don't you fix it? <br />
<strong>A:</strong> Our goal is to produce a build output that is as close as technically
possible to the old build output. If things were weird in the old build, they
will be weird in the new build. Often, things were weird before due to
obscurity, but in the new build system the weird stuff comes up to the surface.
The plan is to attack these things at a later stage, after the new build system
is established.</p>
<p><strong>Q:</strong> The code in the new build system is not that well-structured. Will you
fix this? <br />
<strong>A:</strong> Yes! The new build system has grown bit by bit as we converted the old
system. When all of the old build system is converted, we can take a step back
and clean up the structure of the new build system. Some of this we plan to do
before replacing the old build system and some will need to wait until after.</p>
<p><strong>Q:</strong> Is anything able to use the results of the new build's default make
target? <br />
<strong>A:</strong> Yes, this is the minimal (or roughly minimal) set of compiled output
needed for a developer to actually execute the newly built JDK. The idea is
that in an incremental development fashion, when doing a normal make, you
should only spend time recompiling what's changed (making it purely
incremental) and only do the work that's needed to actually run and test your
code. The packaging stuff that is part of the <code>images</code> target is not needed for
a normal developer who wants to test his new code. Even if it's quite fast,
it's still unnecessary. We're targeting sub-second incremental rebuilds! ;-)
(Or, well, at least single-digit seconds...)</p>
<p><strong>Q:</strong> I usually set a specific environment variable when building, but I can't
find the equivalent in the new build. What should I do? <br />
<strong>A:</strong> It might very well be that we have neglected to add support for an
option that was actually used from outside the build system. Email us and we
will add support for it!</p>
<p><a name="performance"></a></p>
<h3>Build Performance Tips</h3>
<p>Building OpenJDK requires a lot of horsepower. Some of the build tools can be
adjusted to utilize more or less of resources such as parallel threads and
memory. The <code>configure</code> script analyzes your system and selects reasonable
values for such options based on your hardware. If you encounter resource
problems, such as out of memory conditions, you can modify the detected values
with:</p>
<ul>
<li><strong><code>--with-num-cores</code></strong> -- number of cores in the build system, e.g.
<code>--with-num-cores=8</code></li>
<li><strong><code>--with-memory-size</code></strong> -- memory (in MB) available in the build system,
e.g. <code>--with-memory-size=1024</code></li>
</ul>
<p>It might also be necessary to specify the JVM arguments passed to the Bootstrap
JDK, using e.g. <code>--with-boot-jdk-jvmargs="-Xmx8G -enableassertions"</code>. Doing
this will override the default JVM arguments passed to the Bootstrap JDK.</p>
<p>One of the top goals of the new build system is to improve the build
performance and decrease the time needed to build. This will soon also apply to
the java compilation when the Smart Javac wrapper is making its way into jdk8.
It can be tried in the build-infra repository already. You are likely to find
that the new build system is faster than the old one even without this feature.</p>
<p>At the end of a successful execution of <code>configure</code>, you will get a performance
summary, indicating how well the build will perform. Here you will also get
performance hints. If you want to build fast, pay attention to those!</p>
<h4>Building with ccache</h4>
<p>A simple way to radically speed up compilation of native code
(typically hotspot and native libraries in JDK) is to install
ccache. This will cache and reuse prior compilation results, if the
source code is unchanged. However, ccache versions prior to 3.1.4 does
not work correctly with the precompiled headers used in OpenJDK. So if
your platform supports ccache at 3.1.4 or later, we highly recommend
installing it. This is currently only supported on linux.</p>
<h4>Building on local disk</h4>
<p>If you are using network shares, e.g. via NFS, for your source code, make sure
the build directory is situated on local disk. The performance penalty is
extremely high for building on a network share, close to unusable.</p>
<h4>Building only one JVM</h4>
<p>The old build builds multiple JVMs on 32-bit systems (client and server; and on
Windows kernel as well). In the new build we have changed this default to only
build server when it's available. This improves build times for those not
interested in multiple JVMs. To mimic the old behavior on platforms that
support it, use <code>--with-jvm-variants=client,server</code>.</p>
<h4>Selecting the number of cores to build on</h4>
<p>By default, <code>configure</code> will analyze your machine and run the make process in
parallel with as many threads as you have cores. This behavior can be
overridden, either "permanently" (on a <code>configure</code> basis) using
<code>--with-num-cores=N</code> or for a single build only (on a make basis), using
<code>make JOBS=N</code>.</p>
<p>If you want to make a slower build just this time, to save some CPU power for
other processes, you can run e.g. <code>make JOBS=2</code>. This will force the makefiles
to only run 2 parallel processes, or even <code>make JOBS=1</code> which will disable
parallelism.</p>
<p>If you want to have it the other way round, namely having slow builds default
and override with fast if you're impatient, you should call <code>configure</code> with
<code>--with-num-cores=2</code>, making 2 the default. If you want to run with more cores,
run <code>make JOBS=8</code></p>
<p><a name="troubleshooting"></a></p>
<h3>Troubleshooting</h3>
<h4>Solving build problems</h4>
<p>If the build fails (and it's not due to a compilation error in a source file
you've changed), the first thing you should do is to re-run the build with more
verbosity. Do this by adding <code>LOG=debug</code> to your make command line.</p>
<p>The build log (with both stdout and stderr intermingled, basically the same as
you see on your console) can be found as <code>build.log</code> in your build directory.</p>
<p>You can ask for help on build problems with the new build system on either the
<a href="http://mail.openjdk.java.net/mailman/listinfo/build-dev">build-dev</a> or the
<a href="http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev">build-infra-dev</a>
mailing lists. Please include the relevant parts of the build log.</p>
<p>A build can fail for any number of reasons. Most failures are a result of
trying to build in an environment in which all the pre-build requirements have
not been met. The first step in troubleshooting a build failure is to recheck
that you have satisfied all the pre-build requirements for your platform.
Scanning the <code>configure</code> log is a good first step, making sure that what it
found makes sense for your system. Look for strange error messages or any
difficulties that <code>configure</code> had in finding things.</p>
<p>Some of the more common problems with builds are briefly described below, with
suggestions for remedies.</p>
<ul>
<li><p><strong>Corrupted Bundles on Windows:</strong> <br />
Some virus scanning software has been known to corrupt the downloading of
zip bundles. It may be necessary to disable the 'on access' or 'real time'
virus scanning features to prevent this corruption. This type of 'real time'
virus scanning can also slow down the build process significantly.
Temporarily disabling the feature, or excluding the build output directory
may be necessary to get correct and faster builds.</p></li>
<li><p><strong>Slow Builds:</strong> <br />
If your build machine seems to be overloaded from too many simultaneous C++
compiles, try setting the <code>JOBS=1</code> on the <code>make</code> command line. Then try
increasing the count slowly to an acceptable level for your system. Also:</p>
<p>Creating the javadocs can be very slow, if you are running javadoc, consider
skipping that step.</p>
<p>Faster CPUs, more RAM, and a faster DISK usually helps. The VM build tends
to be CPU intensive (many C++ compiles), and the rest of the JDK will often
be disk intensive.</p>
<p>Faster compiles are possible using a tool called