1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
|
2 <html> |
1 <html> |
3 <head> |
2 <head> |
4 <title>OpenJDK Build README</title> |
3 <title>OpenJDK Build README</title> |
5 </head> |
4 </head> |
6 <body style="background-color:aquamarine"> |
5 <body> |
7 |
6 <p><img src="http://openjdk.java.net/images/openjdk.png" alt="OpenJDK" title="" /></p> |
8 <!-- ====================================================== --> |
7 |
9 <table width="100%"> |
8 <h1>OpenJDK Build README</h1> |
10 <tr> |
9 |
11 <td align="center"> |
10 <hr /> |
12 <img alt="OpenJDK" |
11 |
13 src="http://openjdk.java.net/images/openjdk.png" |
12 <p><a name="introduction"></a></p> |
14 width=256> |
13 |
15 </td> |
14 <h2>Introduction</h2> |
16 </tr> |
15 |
17 <tr> |
16 <p>This README file contains build instructions for the |
18 <td align=center> |
17 <a href="http://openjdk.java.net">OpenJDK</a>. Building the source code for the OpenJDK |
19 <h1>OpenJDK Build README</h1> |
18 requires a certain degree of technical expertise.</p> |
20 </td> |
19 |
21 </tr> |
20 <h3>!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!</h3> |
22 </table> |
21 |
23 |
22 <p>Some Headlines:</p> |
24 <!-- ====================================================== --> |
23 |
25 <hr> |
24 <ul> |
26 <h2><a name="introduction">Introduction</a></h2> |
25 <li>The build is now a "<code>configure && make</code>" style build</li> |
27 <blockquote> |
26 <li>Any GNU make 3.81 or newer should work, except on Windows where 4.0 or newer |
28 This README file contains build instructions for the |
27 is recommended.</li> |
29 <a href="http://openjdk.java.net" target="_blank">OpenJDK</a>. |
28 <li>The build should scale, i.e. more processors should cause the build to be |
30 Building the source code for the |
29 done in less wall-clock time</li> |
31 OpenJDK |
30 <li>Nested or recursive make invocations have been significantly reduced, |
32 requires |
31 as has the total fork/exec or spawning of sub processes during the build</li> |
33 a certain degree of technical expertise. |
32 <li>Windows MKS usage is no longer supported</li> |
34 |
33 <li>Windows Visual Studio <code>vsvars*.bat</code> and <code>vcvars*.bat</code> files are run |
35 <!-- ====================================================== --> |
34 automatically</li> |
36 <h3>!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!</h3> |
35 <li>Ant is no longer used when building the OpenJDK</li> |
37 <blockquote> |
36 <li>Use of ALT_* environment variables for configuring the build is no longer |
38 Some Headlines: |
37 supported</li> |
39 <ul> |
38 </ul> |
40 <li> |
39 |
41 The build is now a "<code>configure && make</code>" style build |
40 <hr /> |
42 </li> |
41 |
43 <li> |
42 <h2>Contents</h2> |
44 Any GNU make 3.81 or newer should work, except on |
43 |
45 Windows where 4.0 or newer is recommended. |
44 <ul> |
46 </li> |
45 <li><a href="#introduction">Introduction</a></li> |
47 <li> |
46 <li><a href="#hg">Use of Mercurial</a> |
48 The build should scale, i.e. more processors should |
47 <ul> |
49 cause the build to be done in less wall-clock time |
48 <li><a href="#get_source">Getting the Source</a></li> |
50 </li> |
49 <li><a href="#repositories">Repositories</a></li> |
51 <li> |
50 </ul></li> |
52 Nested or recursive make invocations have been significantly |
51 <li><a href="#building">Building</a> |
53 reduced, as has the total fork/exec or spawning |
52 <ul> |
54 of sub processes during the build |
53 <li><a href="#setup">System Setup</a> |
55 </li> |
54 <ul> |
56 <li> |
55 <li><a href="#linux">Linux</a></li> |
57 Windows MKS usage is no longer supported |
56 <li><a href="#solaris">Solaris</a></li> |
58 </li> |
57 <li><a href="#macosx">Mac OS X</a></li> |
59 <li> |
58 <li><a href="#windows">Windows</a></li> |
60 Windows Visual Studio <code>vsvars*.bat</code> and |
59 </ul></li> |
61 <code>vcvars*.bat</code> files are run automatically |
60 <li><a href="#configure">Configure</a></li> |
62 </li> |
61 <li><a href="#make">Make</a></li> |
63 <li> |
62 </ul></li> |
64 Ant is no longer used when building the OpenJDK |
63 <li><a href="#testing">Testing</a></li> |
65 </li> |
64 </ul> |
66 <li> |
65 |
67 Use of ALT_* environment variables for configuring the |
66 <hr /> |
68 build is no longer supported |
67 |
69 </li> |
68 <ul> |
70 </ul> |
69 <li><a href="#hints">Appendix A: Hints and Tips</a> |
71 </blockquote> |
70 <ul> |
72 </blockquote> |
71 <li><a href="#faq">FAQ</a></li> |
73 |
72 <li><a href="#performance">Build Performance Tips</a></li> |
74 <!-- ====================================================== --> |
73 <li><a href="#troubleshooting">Troubleshooting</a></li> |
75 <hr> |
74 </ul></li> |
76 <h2><a name="contents">Contents</a></h2> |
75 <li><a href="#gmake">Appendix B: GNU Make Information</a></li> |
77 <blockquote> |
76 <li><a href="#buildenvironments">Appendix C: Build Environments</a></li> |
78 <ul> |
77 </ul> |
79 <li><a href="#introduction">Introduction</a></li> |
78 |
80 |
79 <hr /> |
81 <li><a href="#hg">Use of Mercurial</a> |
80 |
82 <ul> |
81 <p><a name="hg"></a></p> |
83 <li><a href="#get_source">Getting the Source</a></li> |
82 |
84 <li><a href="#repositories">Repositories</a></li> |
83 <h2>Use of Mercurial</h2> |
85 </ul> |
84 |
86 </li> |
85 <p>The OpenJDK sources are maintained with the revision control system |
87 |
86 <a href="http://mercurial.selenic.com/wiki/Mercurial">Mercurial</a>. If you are new to |
88 <li><a href="#building">Building</a> |
87 Mercurial, please see the <a href="http://mercurial.selenic.com/wiki/ |
89 <ul> |
88 BeginnersGuides">Beginner Guides</a> or refer to the <a href="http://hgbook.red-bean.com/">Mercurial Book</a>. |
90 <li><a href="#setup">System Setup</a> |
89 The first few chapters of the book provide an excellent overview of Mercurial, |
91 <ul> |
90 what it is and how it works.</p> |
92 <li><a href="#linux">Linux</a></li> |
91 |
93 <li><a href="#solaris">Solaris</a></li> |
92 <p>For using Mercurial with the OpenJDK refer to the <a href="http://openjdk.java.net/guide/ |
94 <li><a href="#macosx">Mac OS X</a></li> |
93 repositories.html#installConfig">Developer Guide: Installing |
95 <li><a href="#windows">Windows</a></li> |
94 and Configuring Mercurial</a> section for more information.</p> |
96 </ul> |
95 |
97 </li> |
96 <p><a name="get_source"></a></p> |
98 <li><a href="#configure">Configure</a></li> |
97 |
99 <li><a href="#make">Make</a></li> |
98 <h3>Getting the Source</h3> |
100 </ul> |
99 |
101 </li> |
100 <p>To get the entire set of OpenJDK Mercurial repositories use the script |
102 <li><a href="#testing">Testing</a></li> |
101 <code>get_source.sh</code> located in the root repository:</p> |
103 </ul> |
102 |
104 <hr> |
103 <pre><code> hg clone http://hg.openjdk.java.net/jdk9/jdk9 YourOpenJDK |
105 <ul> |
104 cd YourOpenJDK |
106 <li><a href="#hints">Appendix A: Hints and Tips</a> |
105 bash ./get_source.sh |
107 <ul> |
106 </code></pre> |
108 <li><a href="#faq">FAQ</a></li> |
107 |
109 <li><a href="#performance">Build Performance Tips</a></li> |
108 <p>Once you have all the repositories, keep in mind that each repository is its |
110 <li><a href="#troubleshooting">Troubleshooting</a></li> |
109 own independent repository. You can also re-run <code>./get_source.sh</code> anytime to |
111 </ul> |
110 pull over all the latest changesets in all the repositories. This set of |
112 </li> |
111 nested repositories has been given the term "forest" and there are various |
113 <li><a href="#gmake">Appendix B: GNU Make Information</a></li> |
112 ways to apply the same <code>hg</code> command to each of the repositories. For |
114 <li><a href="#buildenvironments">Appendix C: Build Environments</a></li> |
113 example, the script <code>make/scripts/hgforest.sh</code> can be used to repeat the |
115 |
114 same <code>hg</code> command on every repository, e.g.</p> |
116 <!-- Leave out |
115 |
117 <li><a href="#mapping">Appendix D: Mapping Old Builds to the New Builds</a></li> |
116 <pre><code> cd YourOpenJDK |
118 --> |
117 bash ./make/scripts/hgforest.sh status |
119 |
118 </code></pre> |
120 </ul> |
119 |
121 </blockquote> |
120 <p><a name="repositories"></a></p> |
122 |
121 |
123 <!-- ====================================================== --> |
122 <h3>Repositories</h3> |
124 <hr> |
123 |
125 <h2><a name="hg">Use of Mercurial</a></h2> |
124 <p>The set of repositories and what they contain:</p> |
126 <blockquote> |
125 |
127 The OpenJDK sources are maintained with the revision control system |
126 <ul> |
128 <a href="http://mercurial.selenic.com/wiki/Mercurial">Mercurial</a>. |
127 <li><strong>. (root)</strong> contains common configure and makefile logic</li> |
129 If you are new to Mercurial, please see the |
128 <li><strong>hotspot</strong> contains source code and make files for building the OpenJDK |
130 <a href="http://mercurial.selenic.com/wiki/BeginnersGuides"> |
129 Hotspot Virtual Machine</li> |
131 Beginner Guides</a> |
130 <li><strong>langtools</strong> contains source code for the OpenJDK javac and language tools</li> |
132 or refer to the <a href="http://hgbook.red-bean.com/"> |
131 <li><strong>jdk</strong> contains source code and make files for building the OpenJDK runtime |
133 Mercurial Book</a>. |
132 libraries and misc files</li> |
134 The first few chapters of the book provide an excellent overview of |
133 <li><strong>jaxp</strong> contains source code for the OpenJDK JAXP functionality</li> |
135 Mercurial, what it is and how it works. |
134 <li><strong>jaxws</strong> contains source code for the OpenJDK JAX-WS functionality</li> |
136 <br> |
135 <li><strong>corba</strong> contains source code for the OpenJDK Corba functionality</li> |
137 For using Mercurial with the OpenJDK refer to the |
136 <li><strong>nashorn</strong> contains source code for the OpenJDK JavaScript implementation</li> |
138 <a href="http://openjdk.java.net/guide/repositories.html#installConfig"> |
137 </ul> |
139 Developer Guide: Installing and Configuring Mercurial</a> |
138 |
140 section for more information. |
139 <h3>Repository Source Guidelines</h3> |
141 |
140 |
142 <h3><a name="get_source">Getting the Source</a></h3> |
141 <p>There are some very basic guidelines:</p> |
143 <blockquote> |
142 |
144 To get the entire set of OpenJDK Mercurial repositories |
143 <ul> |
145 use the script <code>get_source.sh</code> located in the |
144 <li>Use of whitespace in source files (.java, .c, .h, .cpp, and .hpp files) is |
146 root repository: |
145 restricted. No TABs, no trailing whitespace on lines, and files should not |
147 <blockquote> |
146 terminate in more than one blank line.</li> |
148 <code> |
147 <li>Files with execute permissions should not be added to the source |
149 hg clone http://hg.openjdk.java.net/jdk9/jdk9 |
148 repositories.</li> |
150 <i>YourOpenJDK</i> |
149 <li>All generated files need to be kept isolated from the files maintained or |
151 <br> |
150 managed by the source control system. The standard area for generated files |
152 cd <i>YourOpenJDK</i> |
151 is the top level <code>build/</code> directory.</li> |
153 <br> |
152 <li>The default build process should be to build the product and nothing else, |
154 bash ./get_source.sh |
153 in one form, e.g. a product (optimized), debug (non-optimized, -g plus |
155 </code> |
154 assert logic), or fastdebug (optimized, -g plus assert logic).</li> |
156 </blockquote> |
155 <li>The <code>.hgignore</code> file in each repository must exist and should include |
157 Once you have all the repositories, keep in mind that each |
156 <code>^build/</code>, <code>^dist/</code> and optionally any <code>nbproject/private</code> directories. <strong>It |
158 repository is its own independent repository. |
157 should NEVER</strong> include anything in the <code>src/</code> or <code>test/</code> or any managed |
159 You can also re-run <code>./get_source.sh</code> anytime to |
158 directory area of a repository.</li> |
160 pull over all the latest changesets in all the repositories. |
159 <li>Directory names and file names should never contain blanks or non-printing |
161 This set of nested repositories has been given the term |
160 characters.</li> |
162 "forest" and there are various ways to apply the same |
161 <li>Generated source or binary files should NEVER be added to the repository |
163 <code>hg</code> command to each of the repositories. |
162 (that includes <code>javah</code> output). There are some exceptions to this rule, in |
164 For example, the script <code>make/scripts/hgforest.sh</code> |
163 particular with some of the generated configure scripts.</li> |
165 can be used to repeat the same <code>hg</code> |
164 <li>Files not needed for typical building or testing of the repository should |
166 command on every repository, e.g. |
165 not be added to the repository.</li> |
167 <blockquote> |
166 </ul> |
168 <code> |
167 |
169 cd <i>YourOpenJDK</i> |
168 <hr /> |
170 <br> |
169 |
171 bash ./make/scripts/hgforest.sh status |
170 <p><a name="building"></a></p> |
172 </code> |
171 |
173 </blockquote> |
172 <h2>Building</h2> |
174 </blockquote> |
173 |
175 |
174 <p>The very first step in building the OpenJDK is making sure the system itself |
176 <h3><a name="repositories">Repositories</a></h3> |
175 has everything it needs to do OpenJDK builds. Once a system is setup, it |
177 <blockquote> |
176 generally doesn't need to be done again.</p> |
178 <p>The set of repositories and what they contain:</p> |
177 |
179 <table border="1"> |
178 <p>Building the OpenJDK is now done with running a <code>configure</code> script which will |
180 <thead> |
179 try and find and verify you have everything you need, followed by running |
181 <tr> |
180 <code>make</code>, e.g.</p> |
182 <th>Repository</th> |
181 |
183 <th>Contains</th> |
182 <blockquote> |
184 </tr> |
183 <p><strong><code>bash ./configure</code></strong> <br /> |
185 </thead> |
184 <strong><code>make all</code></strong></p> |
186 <tbody> |
185 </blockquote> |
187 <tr> |
186 |
188 <td> |
187 <p>Where possible the <code>configure</code> script will attempt to located the various |
189 . (root) |
188 components in the default locations or via component specific variable |
190 </td> |
189 settings. When the normal defaults fail or components cannot be found, |
191 <td> |
190 additional <code>configure</code> options may be necessary to help <code>configure</code> find the |
192 common configure and makefile logic |
191 necessary tools for the build, or you may need to re-visit the setup of your |
193 </td> |
192 system due to missing software packages.</p> |
194 </tr> |
193 |
195 <tr> |
194 <p><strong>NOTE:</strong> The <code>configure</code> script file does not have execute permissions and |
196 <td> |
195 will need to be explicitly run with <code>bash</code>, see the source guidelines.</p> |
197 hotspot |
196 |
198 </td> |
197 <hr /> |
199 <td> |
198 |
200 source code and make files for building |
199 <p><a name="setup"></a></p> |
201 the OpenJDK Hotspot Virtual Machine |
200 |
202 </td> |
201 <h3>System Setup</h3> |
203 </tr> |
202 |
204 <tr> |
203 <p>Before even attempting to use a system to build the OpenJDK there are some very |
205 <td> |
204 basic system setups needed. For all systems:</p> |
206 langtools |
205 |
207 </td> |
206 <ul> |
208 <td> |
207 <li><p>Be sure the GNU make utility is version 3.81 (4.0 on windows) or newer, e.g. |
209 source code for the OpenJDK javac and language tools |
208 run "<code>make -version</code>"</p> |
210 </td> |
209 |
211 </tr> |
210 <p><a name="bootjdk"></a></p></li> |
212 <tr> |
211 <li><p>Install a Bootstrap JDK. All OpenJDK builds require access to a previously |
213 <td> |
212 released JDK called the <em>bootstrap JDK</em> or <em>boot JDK.</em> The general rule is |
214 jdk |
213 that the bootstrap JDK must be an instance of the previous major release of |
215 </td> |
214 the JDK. In addition, there may be a requirement to use a release at or |
216 <td> |
215 beyond a particular update level.</p> |
217 source code and make files for building |
216 |
218 the OpenJDK runtime libraries and misc files |
217 <p><strong><em>Building JDK 9 requires JDK 8. JDK 9 developers should not use JDK 9 as |
219 </td> |
218 the boot JDK, to ensure that JDK 9 dependencies are not introduced into the |
220 </tr> |
219 parts of the system that are built with JDK 8.</em></strong></p> |
221 <tr> |
220 |
222 <td> |
221 <p>The JDK 8 binaries can be downloaded from Oracle's <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html">JDK 8 download |
223 jaxp |
222 site</a>. |
224 </td> |
223 For build performance reasons it is very important that this bootstrap JDK |
225 <td> |
224 be made available on the local disk of the machine doing the build. You |
226 source code for the OpenJDK JAXP functionality |
225 should add its <code>bin</code> directory to the <code>PATH</code> environment variable. If |
227 </td> |
226 <code>configure</code> has any issues finding this JDK, you may need to use the |
228 </tr> |
227 <code>configure</code> option <code>--with-boot-jdk</code>.</p></li> |
229 <tr> |
228 <li><p>Ensure that GNU make, the Bootstrap JDK, and the compilers are all in your |
230 <td> |
229 PATH environment variable.</p></li> |
231 jaxws |
230 </ul> |
232 </td> |
231 |
233 <td> |
232 <p>And for specific systems:</p> |
234 source code for the OpenJDK JAX-WS functionality |
233 |
235 </td> |
234 <ul> |
236 </tr> |
235 <li><p><strong>Linux</strong></p> |
237 <tr> |
236 |
238 <td> |
237 <p>Install all the software development packages needed including |
239 corba |
238 <a href="#alsa">alsa</a>, <a href="#freetype">freetype</a>, <a href="#cups">cups</a>, and |
240 </td> |
239 <a href="#xrender">xrender</a>. See <a href="#SDBE">specific system packages</a>.</p></li> |
241 <td> |
240 <li><p><strong>Solaris</strong></p> |
242 source code for the OpenJDK Corba functionality |
241 |
243 </td> |
242 <p>Install all the software development packages needed including <a href="#studio">Studio |
244 </tr> |
243 Compilers</a>, <a href="#freetype">freetype</a>, <a href="#cups">cups</a>, and |
245 <tr> |
244 <a href="#xrender">xrender</a>. See <a href="#SDBE">specific system packages</a>.</p></li> |
246 <td> |
245 <li><p><strong>Windows</strong></p> |
247 nashorn |
246 |
248 </td> |
247 <ul> |
249 <td> |
248 <li>Install one of <a href="#cygwin">CYGWIN</a> or <a href="#msys">MinGW/MSYS</a></li> |
250 source code for the OpenJDK JavaScript implementation |
249 <li>Install <a href="#vs2013">Visual Studio 2013</a></li> |
251 </td> |
250 </ul></li> |
252 </tr> |
251 <li><p><strong>Mac OS X</strong></p> |
253 </tbody> |
252 |
254 </table> |
253 <p>Install <a href="https://developer.apple.com/xcode/">XCode 4.5.2</a> and also |
255 </blockquote> |
254 install the "Command line tools" found under the preferences pane |
256 |
255 "Downloads"</p></li> |
257 <h3><a name="guidelines">Repository Source Guidelines</a></h3> |
256 </ul> |
258 <blockquote> |
257 |
259 There are some very basic guidelines: |
258 <p><a name="linux"></a></p> |
260 <ul> |
259 |
261 <li> |
260 <h4>Linux</h4> |
262 Use of whitespace in source files |
261 |
263 (.java, .c, .h, .cpp, and .hpp files) |
262 <p>With Linux, try and favor the system packages over building your own or getting |
264 is restricted. |
263 packages from other areas. Most Linux builds should be possible with the |
265 No TABs, no trailing whitespace on lines, and files |
264 system's available packages.</p> |
266 should not terminate in more than one blank line. |
265 |
267 </li> |
266 <p>Note that some Linux systems have a habit of pre-populating your environment |
268 <li> |
267 variables for you, for example <code>JAVA_HOME</code> might get pre-defined for you to |
269 Files with execute permissions should not be added |
268 refer to the JDK installed on your Linux system. You will need to unset |
270 to the source repositories. |
269 <code>JAVA_HOME</code>. It's a good idea to run <code>env</code> and verify the environment variables |
271 </li> |
270 you are getting from the default system settings make sense for building the |
272 <li> |
271 OpenJDK.</p> |
273 All generated files need to be kept isolated from |
272 |
274 the files |
273 <p><a name="solaris"></a></p> |
275 maintained or managed by the source control system. |
274 |
276 The standard area for generated files is the top level |
275 <h4>Solaris</h4> |
277 <code>build/</code> directory. |
276 |
278 </li> |
277 <p><a name="studio"></a></p> |
279 <li> |
278 |
280 The default build process should be to build the product |
279 <h5>Studio Compilers</h5> |
281 and nothing else, in one form, e.g. a product (optimized), |
280 |
282 debug (non-optimized, -g plus assert logic), or |
281 <p>At a minimum, the <a href="http://www.oracle.com/ |
283 fastdebug (optimized, -g plus assert logic). |
282 technetwork/server-storage/solarisstudio/downloads/index.htm">Studio 12 Update 1 Compilers</a> (containing |
284 </li> |
283 version 5.10 of the C and C++ compilers) is required, including specific |
285 <li> |
284 patches.</p> |
286 The <tt>.hgignore</tt> file in each repository |
285 |
287 must exist and should |
286 <p>The Solaris SPARC patch list is:</p> |
288 include <tt>^build/</tt>, <tt>^dist/</tt> and |
287 |
289 optionally any |
288 <ul> |
290 <tt>nbproject/private</tt> directories. |
289 <li>118683-05: SunOS 5.10: Patch for profiling libraries and assembler</li> |
291 <strong>It should NEVER</strong> include |
290 <li>119963-21: SunOS 5.10: Shared library patch for C++</li> |
292 anything in the |
291 <li>120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch</li> |
293 <tt>src/</tt> or <tt>test/</tt> |
292 <li>128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler</li> |
294 or any managed directory area of a repository. |
293 <li>141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C |
295 </li> |
294 C++ F77 F95</li> |
296 <li> |
295 <li>141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler</li> |
297 Directory names and file names should never contain |
296 <li>142371-01: Sun Studio 12.1 Update 1: Patch for dbx</li> |
298 blanks or |
297 <li>143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling</li> |
299 non-printing characters. |
298 <li>143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C |
300 </li> |
299 C++ F77 F95</li> |
301 <li> |
300 <li>142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools</li> |
302 Generated source or binary files should NEVER be added to |
301 </ul> |
303 the repository (that includes <tt>javah</tt> output). |
302 |
304 There are some exceptions to this rule, in particular |
303 <p>The Solaris X86 patch list is:</p> |
305 with some of the generated configure scripts. |
304 |
306 </li> |
305 <ul> |
307 <li> |
306 <li>119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler</li> |
308 Files not needed for typical building |
307 <li>119964-21: SunOS 5.10_x86: Shared library patch for C++_x86</li> |
309 or testing of the repository |
308 <li>120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch</li> |
310 should not be added to the repository. |
309 <li>141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 |
311 </li> |
310 backend</li> |
312 </ul> |
311 <li>128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler</li> |
313 </blockquote> |
312 <li>142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler</li> |
314 |
313 <li>142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools</li> |
315 </blockquote> |
314 </ul> |
316 |
315 |
317 <!-- ====================================================== --> |
316 <p>Place the <code>bin</code> directory in <code>PATH</code>.</p> |
318 <hr> |
317 |
319 <h2><a name="building">Building</a></h2> |
318 <p>The Oracle Solaris Studio Express compilers at: <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/ |
320 <blockquote> |
319 downloads/index-jsp-142582.html">Oracle Solaris Studio Express |
321 The very first step in building the OpenJDK is making sure the |
320 Download site</a> are also an option, although these compilers |
322 system itself has everything it needs to do OpenJDK builds. |
321 have not been extensively used yet.</p> |
323 Once a system is setup, it generally doesn't need to be done again. |
322 |
324 <br> |
323 <p><a name="windows"></a></p> |
325 Building the OpenJDK is now done with running a |
324 |
326 <a href="#configure"><code>configure</code></a> |
325 <h4>Windows</h4> |
327 script which will try and find and verify you have everything |
326 |
328 you need, followed by running |
327 <h5>Windows Unix Toolkit</h5> |
329 <a href="#gmake"><code>make</code></a>, e.g. |
328 |
330 <blockquote> |
329 <p>Building on Windows requires a Unix-like environment, notably a Unix-like |
331 <b> |
330 shell. There are several such environments available of which |
332 <code> |
331 <a href="http://www.cygwin.com/">Cygwin</a> and |
333 bash ./configure<br> |
332 <a href="http://www.mingw.org/wiki/MSYS">MinGW/MSYS</a> are currently supported for the |
334 make all |
333 OpenJDK build. One of the differences of these systems from standard Windows |
335 </code> |
334 tools is the way they handle Windows path names, particularly path names which |
336 </b> |
335 contain spaces, backslashes as path separators and possibly drive letters. |
337 </blockquote> |
336 Depending on the use case and the specifics of each environment these path |
338 Where possible the <code>configure</code> script will attempt to located the |
337 problems can be solved by a combination of quoting whole paths, translating |
339 various components in the default locations or via component |
338 backslashes to forward slashes, escaping backslashes with additional |
340 specific variable settings. |
339 backslashes and translating the path names to their <a href="http://en.wikipedia.org/wiki/8.3_filename">"8.3" |
341 When the normal defaults fail or components cannot be found, |
340 version</a>.</p> |
342 additional <code>configure</code> options may be necessary to help <code>configure</code> |
341 |
343 find the necessary tools for the build, or you may need to |
342 <p><a name="cygwin"></a></p> |
344 re-visit the setup of your system due to missing software |
343 |
345 packages. |
344 <h6>CYGWIN</h6> |
346 <br> |
345 |
347 <strong>NOTE:</strong> The <code>configure</code> script |
346 <p>CYGWIN is an open source, Linux-like environment which tries to emulate a |
348 file does not have |
347 complete POSIX layer on Windows. It tries to be smart about path names and can |
349 execute permissions and will need to be explicitly run with |
348 usually handle all kinds of paths if they are correctly quoted or escaped |
350 <code>bash</code>, |
349 although internally it maps drive letters <code><drive>:</code> to a virtual directory |
351 see the <a href="#guidelines">source guidelines</a>. |
350 <code>/cygdrive/<drive></code>.</p> |
352 |
351 |
353 <!-- ====================================================== --> |
352 <p>You can always use the <code>cygpath</code> utility to map pathnames with spaces or the |
354 <hr> |
353 backslash character into the <code>C:/</code> style of pathname (called 'mixed'), e.g. |
355 <h3><a name="setup">System Setup</a></h3> |
354 <code>cygpath -s -m "<path>"</code>.</p> |
356 <blockquote> |
355 |
357 Before even attempting to use a system to build the OpenJDK |
356 <p>Note that the use of CYGWIN creates a unique problem with regards to setting |
358 there are some very basic system setups needed. |
357 <a href="#path"><code>PATH</code></a>. Normally on Windows the <code>PATH</code> variable contains directories |
359 For all systems: |
358 separated with the ";" character (Solaris and Linux use ":"). With CYGWIN, it |
360 <ul> |
359 uses ":", but that means that paths like "C:/path" cannot be placed in the |
361 <li> |
360 CYGWIN version of <code>PATH</code> and instead CYGWIN uses something like |
362 Be sure the GNU make utility is version 3.81 (4.0 on |
361 <code>/cygdrive/c/path</code> which CYGWIN understands, but only CYGWIN understands.</p> |
363 windows) or newer, e.g. run "<code>make -version</code>" |
362 |
364 </li> |
363 <p>The OpenJDK build requires CYGWIN version 1.7.16 or newer. Information about |
365 <li> |
364 CYGWIN can be obtained from the CYGWIN website at |
366 Install a |
365 <a href="http://www.cygwin.com">www.cygwin.com</a>.</p> |
367 <a name="bootjdk">Bootstrap JDK</a>. |
366 |
368 All OpenJDK builds require access to a previously released |
367 <p>By default CYGWIN doesn't install all the tools required for building the |
369 JDK called the <i>bootstrap JDK</i> or <i>boot JDK.</i> |
368 OpenJDK. Along with the default installation, you need to install the following |
370 The general rule is that the bootstrap JDK |
369 tools.</p> |
371 must be an instance of the previous major |
370 |
372 release of the JDK. In addition, there may be |
371 <blockquote> |
373 a requirement to use a release at or beyond a |
372 <p><table border="1"> |
374 particular update level. |
373 <thead> |
375 <br> <br> |
374 <tr> |
376 |
375 <td>Binary Name</td> |
377 <b><i>Building JDK 9 requires JDK 8. JDK 9 |
376 <td>Category</td> |
378 developers should not use JDK 9 as the boot |
377 <td>Package</td> |
379 JDK, to ensure that JDK 9 dependencies are |
378 <td>Description</td> |
380 not introduced into the parts of the system |
379 </tr> |
381 that are built with JDK 8.</i></b> |
380 </thead> |
382 |
381 <tbody> |
383 <br> <br> |
382 <tr> |
384 The JDK 8 binaries can be downloaded from Oracle's |
383 <td>ar.exe</td> |
385 <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html" |
384 <td>Devel</td> |
386 target="_blank">JDK 8 download site</a>. |
385 <td>binutils</td> |
387 For build performance reasons it |
386 <td>The GNU assembler, linker and binary utilities</td> |
388 is very important that this bootstrap JDK be made available |
387 </tr> |
389 on the local disk of the machine doing the build. |
388 <tr> |
390 You should add its <code>bin</code> directory |
389 <td>make.exe</td> |
391 to the <code>PATH</code> environment variable. |
390 <td>Devel</td> |
392 If <code>configure</code> has any issues finding this JDK, you may |
391 <td>make</td> |
393 need to use the <code>configure</code> option |
392 <td>The GNU version of the 'make' utility built for CYGWIN</td> |
394 <code>--with-boot-jdk</code>. |
393 </tr> |
395 </li> |
394 <tr> |
396 <li> |
395 <td>m4.exe</td> |
397 Ensure that GNU make, the Bootstrap JDK, |
396 <td>Interpreters</td> |
398 and the compilers are all |
397 <td>m4</td> |
399 in your PATH environment variable |
398 <td>GNU implementation of the traditional Unix macro processor</td> |
400 </li> |
399 </tr> |
401 </ul> |
400 <tr> |
402 And for specific systems: |
401 <td>cpio.exe</td> |
403 <table border="1"> |
402 <td>Utils</td> |
404 <thead> |
403 <td>cpio</td> |
405 <tr> |
404 <td>A program to manage archives of files</td> |
406 <th>Linux</th> |
405 </tr> |
407 <th>Solaris</th> |
406 <tr> |
408 <th>Windows</th> |
407 <td>gawk.exe</td> |
409 <th>Mac OS X</th> |
408 <td>Utils</td> |
410 </tr> |
409 <td>awk</td> |
411 </thead> |
410 <td>Pattern-directed scanning and processing language</td> |
412 <tbody> |
411 </tr> |
413 <tr> |
412 <tr> |
414 <td> |
413 <td>file.exe</td> |
415 Install all the software development |
414 <td>Utils</td> |
416 packages needed including |
415 <td>file</td> |
417 <a href="#alsa">alsa</a>, |
416 <td>Determines file type using 'magic' numbers</td> |
418 <a href="#freetype">freetype</a>, |
417 </tr> |
419 <a href="#cups">cups</a>, and |
418 <tr> |
420 <a href="#xrender">xrender</a>. |
419 <td>zip.exe</td> |
421 <br> |
420 <td>Archive</td> |
422 See |
421 <td>zip</td> |
423 <a href="#SDBE">specific system packages</a>. |
422 <td>Package and compress (archive) files</td> |
424 </td> |
423 </tr> |
425 <td> |
424 <tr> |
426 Install all the software development |
425 <td>unzip.exe</td> |
427 packages needed including |
426 <td>Archive</td> |
428 <a href="#studio">Studio Compilers</a>, |
427 <td>unzip</td> |
429 <a href="#freetype">freetype</a>, |
428 <td>Extract compressed files in a ZIP archive</td> |
430 <a href="#cups">cups</a>, and |
429 </tr> |
431 <a href="#xrender">xrender</a>. |
430 <tr> |
432 <br> |
431 <td>free.exe</td> |
433 See |
432 <td>System</td> |
434 <a href="#SDBE">specific system packages</a>. |
433 <td>procps</td> |
435 </td> |
434 <td>Display amount of free and used memory in the system</td> |
436 <td> |
435 </tr> |
437 <ul> |
436 </tbody> |
438 <li> |
437 </table></p> |
439 Install one of |
438 </blockquote> |
440 <a href="#cygwin">CYGWIN</a> or |
439 |
441 <a href="#msys">MinGW/MSYS</a> |
440 <p>Note that the CYGWIN software can conflict with other non-CYGWIN software on |
442 </li> |
441 your Windows system. CYGWIN provides a <a href="http://cygwin.com/faq/ |
443 <li> |
442 faq.using.html">FAQ</a> for known issues and problems, of particular interest is the |
444 Install |
443 section on <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda">BLODA (applications that interfere with |
445 <a href="#vs2013">Visual Studio 2013</a> |
444 CYGWIN)</a>.</p> |
446 </li> |
445 |
447 </ul> |
446 <p><a name="msys"></a></p> |
448 </td> |
447 |
449 <td> |
448 <h6>MinGW/MSYS</h6> |
450 Install |
449 |
451 <a href="https://developer.apple.com/xcode/">XCode 4.5.2</a> |
450 <p>MinGW ("Minimalist GNU for Windows") is a collection of free Windows specific |
452 and also install the "Command line tools" found under the |
451 header files and import libraries combined with GNU toolsets that allow one to |
453 preferences pane "Downloads" |
452 produce native Windows programs that do not rely on any 3rd-party C runtime |
454 </td> |
453 DLLs. MSYS is a supplement to MinGW which allows building applications and |
455 </tr> |
454 programs which rely on traditional UNIX tools to be present. Among others this |
456 </tbody> |
455 includes tools like <code>bash</code> and <code>make</code>. See <a href="http://www.mingw.org/ |
457 </table> |
456 wiki/MSYS">MinGW/MSYS</a> for more information.</p> |
458 |
457 |
459 <h4><a name="linux">Linux</a></h4> |
458 <p>Like Cygwin, MinGW/MSYS can handle different types of path formats. They are |
460 <blockquote> |
459 internally converted to paths with forward slashes and drive letters |
461 With Linux, try and favor the system packages over |
460 <code><drive>:</code> replaced by a virtual directory <code>/<drive></code>. Additionally, MSYS |
462 building your own |
461 automatically detects binaries compiled for the MSYS environment and feeds them |
463 or getting packages from other areas. |
462 with the internal, Unix-style path names. If native Windows applications are |
464 Most Linux builds should be possible with the system's |
463 called from within MSYS programs their path arguments are automatically |
465 available packages. |
464 converted back to Windows style path names with drive letters and backslashes |
466 <br> |
465 as path separators. This may cause problems for Windows applications which use |
467 Note that some Linux systems have a habit of pre-populating |
466 forward slashes as parameter separator (e.g. <code>cl /nologo /I</code>) because MSYS may |
468 your environment variables for you, for example <code>JAVA_HOME</code> |
467 wrongly <a href="http://mingw.org/wiki/ |
469 might get pre-defined for you to refer to the JDK installed on |
468 Posix_path_conversion">replace such parameters by drive letters</a>.</p> |
470 your Linux system. |
469 |
471 You will need to unset <code>JAVA_HOME</code>. |
470 <p>In addition to the tools which will be installed by default, you have to |
472 It's a good idea to run <code>env</code> and verify the |
471 manually install the <code>msys-zip</code> and <code>msys-unzip</code> packages. This can be easily |
473 environment variables you are getting from the default system |
472 done with the MinGW command line installer:</p> |
474 settings make sense for building the OpenJDK. |
473 |
475 |
474 <pre><code> mingw-get.exe install msys-zip |
476 </blockquote> |
475 mingw-get.exe install msys-unzip |
477 |
476 </code></pre> |
478 <h4><a name="solaris">Solaris</a></h4> |
477 |
479 <blockquote> |
478 <p><a name="vs2013"></a></p> |
480 <h5><a name="studio">Studio Compilers</a></h5> |
479 |
481 <blockquote> |
480 <h5>Visual Studio 2013 Compilers</h5> |
482 At a minimum, the |
481 |
483 <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index.htm" target="_blank"> |
482 <p>The 32-bit and 64-bit OpenJDK Windows build requires Microsoft Visual Studio |
484 Studio 12 Update 1 Compilers</a> |
483 C++ 2013 (VS2013) Professional Edition or Express compiler. The compiler and |
485 (containing version 5.10 of the C and C++ compilers) is required, |
484 other tools are expected to reside in the location defined by the variable |
486 including specific patches. |
485 <code>VS120COMNTOOLS</code> which is set by the Microsoft Visual Studio installer.</p> |
487 <p> |
486 |
488 The Solaris SPARC patch list is: |
487 <p>Only the C++ part of VS2013 is needed. Try to let the installation go to the |
489 <ul> |
488 default install directory. Always reboot your system after installing VS2013. |
490 <li> |
489 The system environment variable VS120COMNTOOLS should be set in your |
491 118683-05: SunOS 5.10: Patch for profiling libraries and assembler |
490 environment.</p> |
492 </li> |
491 |
493 <li> |
492 <p>Make sure that TMP and TEMP are also set in the environment and refer to |
494 119963-21: SunOS 5.10: Shared library patch for C++ |
493 Windows paths that exist, like <code>C:\temp</code>, not <code>/tmp</code>, not <code>/cygdrive/c/temp</code>, |
495 </li> |
494 and not <code>C:/temp</code>. <code>C:\temp</code> is just an example, it is assumed that this area |
496 <li> |
495 is private to the user, so by default after installs you should see a unique |
497 120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch |
496 user path in these variables.</p> |
498 </li> |
497 |
499 <li> |
498 <p><a name="macosx"></a></p> |
500 128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler |
499 |
501 </li> |
500 <h4>Mac OS X</h4> |
502 <li> |
501 |
503 141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 |
502 <p>Make sure you get the right XCode version.</p> |
504 </li> |
503 |
505 <li> |
504 <hr /> |
506 141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler |
505 |
507 </li> |
506 <p><a name="configure"></a></p> |
508 <li> |
507 |
509 142371-01: Sun Studio 12.1 Update 1: Patch for dbx |
508 <h3>Configure</h3> |
510 </li> |
509 |
511 <li> |
510 <p>The basic invocation of the <code>configure</code> script looks like:</p> |
512 143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling |
511 |
513 </li> |
512 <blockquote> |
514 <li> |
513 <p><strong><code>bash ./configure [options]</code></strong></p> |
515 143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 |
514 </blockquote> |
516 </li> |
515 |
517 <li> |
516 <p>This will create an output directory containing the "configuration" and setup |
518 142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools |
517 an area for the build result. This directory typically looks like:</p> |
519 </li> |
518 |
520 </ul> |
519 <blockquote> |
521 <p> |
520 <p><strong><code>build/linux-x64-normal-server-release</code></strong></p> |
522 The Solaris X86 patch list is: |
521 </blockquote> |
523 <ul> |
522 |
524 <li> |
523 <p><code>configure</code> will try to figure out what system you are running on and where all |
525 119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler |
524 necessary build components are. If you have all prerequisites for building |
526 </li> |
525 installed, it should find everything. If it fails to detect any component |
527 <li> |
526 automatically, it will exit and inform you about the problem. When this |
528 119964-21: SunOS 5.10_x86: Shared library patch for C++_x86 |
527 happens, read more below in <a href="#configureoptions">the <code>configure</code> options</a>.</p> |
529 </li> |
528 |
530 <li> |
529 <p>Some examples:</p> |
531 120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch |
530 |
532 </li> |
531 <blockquote> |
533 <li> |
532 <p><strong>Windows 32bit build with freetype specified:</strong> <br /> |
534 141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 backend |
533 <code>bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target- |
535 </li> |
534 bits=32</code></p> |
536 <li> |
535 |
537 128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler |
536 <p><strong>Debug 64bit Build:</strong> <br /> |
538 </li> |
537 <code>bash ./configure --enable-debug --with-target-bits=64</code></p> |
539 <li> |
538 </blockquote> |
540 142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler |
539 |
541 </li> |
540 <p><a name="configureoptions"></a></p> |
542 <li> |
541 |
543 142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools |
542 <h4>Configure Options</h4> |
544 </li> |
543 |
545 </ul> |
544 <p>Complete details on all the OpenJDK <code>configure</code> options can be seen with:</p> |
546 <p> |
545 |
547 Place the <code>bin</code> directory in <code>PATH</code>. |
546 <blockquote> |
548 <p> |
547 <p><strong><code>bash ./configure --help=short</code></strong></p> |
549 The Oracle Solaris Studio Express compilers at: |
548 </blockquote> |
550 <a href="http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index-jsp-142582.html" target="_blank"> |
549 |
551 Oracle Solaris Studio Express Download site</a> |
550 <p>Use <code>-help</code> to see all the <code>configure</code> options available. You can generate any |
552 are also an option, although these compilers have not |
551 number of different configurations, e.g. debug, release, 32, 64, etc.</p> |
553 been extensively used yet. |
552 |
554 </blockquote> |
553 <p>Some of the more commonly used <code>configure</code> options are:</p> |
555 |
554 |
556 </blockquote> <!-- Solaris --> |
555 <blockquote> |
557 |
556 <p><strong><code>--enable-debug</code></strong> <br /> |
558 <h4><a name="windows">Windows</a></h4> |
557 set the debug level to fastdebug (this is a shorthand for <code>--with-debug- |
559 <blockquote> |
558 level=fastdebug</code>)</p> |
560 |
559 </blockquote> |
561 <h5><a name="toolkit">Windows Unix Toolkit</a></h5> |
560 |
562 <blockquote> |
561 <p><a name="alsa"></a></p> |
563 Building on Windows requires a Unix-like environment, notably a |
562 |
564 Unix-like shell. |
563 <blockquote> |
565 There are several such environments available of which |
564 <p><strong><code>--with-alsa=</code></strong><em>path</em> <br /> |
566 <a href="http://www.cygwin.com/">Cygwin</a> and |
565 select the location of the Advanced Linux Sound Architecture (ALSA)</p> |
567 <a href="http://www.mingw.org/wiki/MSYS">MinGW/MSYS</a> are |
566 |
568 currently supported for |
567 <p>Version 0.9.1 or newer of the ALSA files are required for building the |
569 the OpenJDK build. One of the differences of these |
568 OpenJDK on Linux. These Linux files are usually available from an "alsa" of |
570 systems from standard Windows tools is the way |
569 "libasound" development package, and it's highly recommended that you try |
571 they handle Windows path names, particularly path names which contain |
570 and use the package provided by the particular version of Linux that you are |
572 spaces, backslashes as path separators and possibly drive letters. |
571 using.</p> |
573 Depending |
572 |
574 on the use case and the specifics of each environment these path |
573 <p><strong><code>--with-boot-jdk=</code></strong><em>path</em> <br /> |
575 problems can |
574 select the <a href="#bootjdk">Bootstrap JDK</a></p> |
576 be solved by a combination of quoting whole paths, translating |
575 |
577 backslashes to |
576 <p><strong><code>--with-boot-jdk-jvmargs=</code></strong>"<em>args</em>" <br /> |
578 forward slashes, escaping backslashes with additional backslashes and |
577 provide the JVM options to be used to run the <a href="#bootjdk">Bootstrap JDK</a></p> |
579 translating the path names to their |
578 |
580 <a href="http://en.wikipedia.org/wiki/8.3_filename"> |
579 <p><strong><code>--with-cacerts=</code></strong><em>path</em> <br /> |
581 "8.3" version</a>. |
580 select the path to the cacerts file.</p> |
582 |
581 |
583 <h6><a name="cygwin">CYGWIN</a></h6> |
582 <p>See <a href="http://en.wikipedia.org/wiki/ |
584 <blockquote> |
583 Certificate_Authority">Certificate Authority on Wikipedia</a> for a better understanding of the Certificate |
585 CYGWIN is an open source, Linux-like environment which tries to emulate |
584 Authority (CA). A certificates file named "cacerts" represents a system-wide |
586 a complete POSIX layer on Windows. It tries to be smart about path names |
585 keystore with CA certificates. In JDK and JRE binary bundles, the "cacerts" |
587 and can usually handle all kinds of paths if they are correctly quoted |
586 file contains root CA certificates from several public CAs (e.g., VeriSign, |
588 or escaped although internally it maps drive letters <code><drive>:</code> |
587 Thawte, and Baltimore). The source contain a cacerts file without CA root |
589 to a virtual directory <code>/cygdrive/<drive></code>. |
588 certificates. Formal JDK builders will need to secure permission from each |
590 <p> |
589 public CA and include the certificates into their own custom cacerts file. |
591 You can always use the <code>cygpath</code> utility to map pathnames with spaces |
590 Failure to provide a populated cacerts file will result in verification |
592 or the backslash character into the <code>C:/</code> style of pathname |
591 errors of a certificate chain during runtime. By default an empty cacerts |
593 (called 'mixed'), e.g. <code>cygpath -s -m "<i>path</i>"</code>. |
592 file is provided and that should be fine for most JDK developers.</p> |
594 </p> |
593 </blockquote> |
595 <p> |
594 |
596 Note that the use of CYGWIN creates a unique problem with regards to |
595 <p><a name="cups"></a></p> |
597 setting <a href="#path"><code>PATH</code></a>. Normally on Windows |
596 |
598 the <code>PATH</code> variable contains directories |
597 <blockquote> |
599 separated with the ";" character (Solaris and Linux use ":"). |
598 <p><strong><code>--with-cups=</code></strong><em>path</em> <br /> |
600 With CYGWIN, it uses ":", but that means that paths like "C:/path" |
599 select the CUPS install location</p> |
601 cannot be placed in the CYGWIN version of <code>PATH</code> and |
600 |
602 instead CYGWIN uses something like <code>/cygdrive/c/path</code> |
601 <p>The Common UNIX Printing System (CUPS) Headers are required for building the |
603 which CYGWIN understands, but only CYGWIN understands. |
602 OpenJDK on Solaris and Linux. The Solaris header files can be obtained by |
604 </p> |
603 installing the package <strong>SFWcups</strong> from the Solaris Software Companion |
605 <p> |
604 CD/DVD, these often will be installed into the directory <code>/opt/sfw/cups</code>.</p> |
606 The OpenJDK build requires CYGWIN version 1.7.16 or newer. |
605 |
607 Information about CYGWIN can |
606 <p>The CUPS header files can always be downloaded from |
608 be obtained from the CYGWIN website at |
607 <a href="http://www.cups.org">www.cups.org</a>.</p> |
609 <a href="http://www.cygwin.com" target="_blank">www.cygwin.com</a>. |
608 |
610 </p> |
609 <p><strong><code>--with-cups-include=</code></strong><em>path</em> <br /> |
611 <p> |
610 select the CUPS include directory location</p> |
612 By default CYGWIN doesn't install all the tools required for building |
611 |
613 the OpenJDK. |
612 <p><strong><code>--with-debug-level=</code></strong><em>level</em> <br /> |
614 Along with the default installation, you need to install |
613 select the debug information level of release, fastdebug, or slowdebug</p> |
615 the following tools. |
614 |
616 <blockquote> |
615 <p><strong><code>--with-dev-kit=</code></strong><em>path</em> <br /> |
617 <table border="1"> |
616 select location of the compiler install or developer install location</p> |
618 <thead> |
617 </blockquote> |
619 <tr> |
618 |
620 <td>Binary Name</td> |
619 <p><a name="freetype"></a></p> |
621 <td>Category</td> |
620 |
622 <td>Package</td> |
621 <blockquote> |
623 <td>Description</td> |
622 <p><strong><code>--with-freetype=</code></strong><em>path</em> <br /> |
624 </tr> |
623 select the freetype files to use.</p> |
625 </thead> |
624 |
626 <tbody> |
625 <p>Expecting the freetype libraries under <code>lib/</code> and the headers under |
627 <tr> |
626 <code>include/</code>.</p> |
628 <td>ar.exe</td> |
627 |
629 <td>Devel</td> |
628 <p>Version 2.3 or newer of FreeType is required. On Unix systems required files |
630 <td>binutils</td> |
629 can be available as part of your distribution (while you still may need to |
631 <td> |
630 upgrade them). Note that you need development version of package that |
632 The GNU assembler, linker and binary utilities |
631 includes both the FreeType library and header files.</p> |
633 </td> |
632 |
634 </tr> |
633 <p>You can always download latest FreeType version from the <a href="http://www.freetype.org">FreeType |
635 <tr> |
634 website</a>. Building the freetype 2 libraries from |
636 <td>make.exe</td> |
635 scratch is also possible, however on Windows refer to the <a href="http://freetype.freedesktop.org/wiki/FreeType_DLL">Windows FreeType |
637 <td>Devel</td> |
636 DLL build instructions</a>.</p> |
638 <td>make</td> |
637 |
639 <td> |
638 <p>Note that by default FreeType is built with byte code hinting support |
640 The GNU version of the 'make' utility built for CYGWIN |
639 disabled due to licensing restrictions. In this case, text appearance and |
641 </td> |
640 metrics are expected to differ from Sun's official JDK build. See the |
642 </tr> |
641 <a href="http://freetype.sourceforge.net/freetype2">SourceForge FreeType2 Home Page</a> |
643 <tr> |
642 for more information.</p> |
644 <td>m4.exe</td> |
643 |
645 <td>Interpreters</td> |
644 <p><strong><code>--with-import-hotspot=</code></strong><em>path</em> <br /> |
646 <td>m4</td> |
645 select the location to find hotspot binaries from a previous build to avoid |
647 <td> |
646 building hotspot</p> |
648 GNU implementation of the traditional Unix macro |
647 |
649 processor |
648 <p><strong><code>--with-target-bits=</code></strong><em>arg</em> <br /> |
650 </td> |
649 select 32 or 64 bit build</p> |
651 </tr> |
650 |
652 <tr> |
651 <p><strong><code>--with-jvm-variants=</code></strong><em>variants</em> <br /> |
653 <td>cpio.exe</td> |
652 select the JVM variants to build from, comma separated list that can |
654 <td>Utils</td> |
653 include: server, client, kernel, zero and zeroshark</p> |
655 <td>cpio</td> |
654 |
656 <td> |
655 <p><strong><code>--with-memory-size=</code></strong><em>size</em> <br /> |
657 A program to manage archives of files |
656 select the RAM size that GNU make will think this system has</p> |
658 </td> |
657 |
659 </tr> |
658 <p><strong><code>--with-msvcr-dll=</code></strong><em>path</em> <br /> |
660 <tr> |
659 select the <code>msvcr100.dll</code> file to include in the Windows builds (C/C++ |
661 <td>gawk.exe</td> |
660 runtime library for Visual Studio).</p> |
662 <td>Utils</td> |
661 |
663 <td>awk</td> |
662 <p>This is usually picked up automatically from the redist directories of |
664 <td> |
663 Visual Studio 2013.</p> |
665 Pattern-directed scanning and processing language |
664 |
666 </td> |
665 <p><strong><code>--with-num-cores=</code></strong><em>cores</em> <br /> |
667 </tr> |
666 select the number of cores to use (processor count or CPU count)</p> |
668 <tr> |
667 </blockquote> |
669 <td>file.exe</td> |
668 |
670 <td>Utils</td> |
669 <p><a name="xrender"></a></p> |
671 <td>file</td> |
670 |
672 <td> |
671 <blockquote> |
673 Determines file type using 'magic' numbers |
672 <p><strong><code>--with-x=</code></strong><em>path</em> <br /> |
674 </td> |
673 select the location of the X11 and xrender files.</p> |
675 </tr> |
674 |
676 <tr> |
675 <p>The XRender Extension Headers are required for building the OpenJDK on |
677 <td>zip.exe</td> |
676 Solaris and Linux. The Linux header files are usually available from a |
678 <td>Archive</td> |
677 "Xrender" development package, it's recommended that you try and use the |
679 <td>zip</td> |
678 package provided by the particular distribution of Linux that you are using. |
680 <td> |
679 The Solaris XRender header files is included with the other X11 header files |
681 Package and compress (archive) files |
680 in the package <strong>SFWxwinc</strong> on new enough versions of Solaris and will be |
682 </td> |
681 installed in <code>/usr/X11/include/X11/extensions/Xrender.h</code> or |
683 </tr> |
682 <code>/usr/openwin/share/include/X11/extensions/Xrender.h</code></p> |
684 <tr> |
683 </blockquote> |
685 <td>unzip.exe</td> |
684 |
686 <td>Archive</td> |
685 <hr /> |
687 <td>unzip</td> |
686 |
688 <td> |
687 <p><a name="make"></a></p> |
689 Extract compressed files in a ZIP archive |
688 |
690 </td> |
689 <h3>Make</h3> |
691 </tr> |
690 |
692 <tr> |
691 <p>The basic invocation of the <code>make</code> utility looks like:</p> |
693 <td>free.exe</td> |
692 |
694 <td>System</td> |
693 <blockquote> |
695 <td>procps</td> |
694 <p><strong><code>make all</code></strong></p> |
696 <td> |
695 </blockquote> |
697 Display amount of free and used memory in the system |
696 |
698 </td> |
697 <p>This will start the build to the output directory containing the |
699 </tr> |
698 "configuration" that was created by the <code>configure</code> script. Run <code>make help</code> for |
700 </tbody> |
699 more information on the available targets.</p> |
701 </table> |
700 |
702 </blockquote> |
701 <p>There are some of the make targets that are of general interest:</p> |
703 Note that the CYGWIN software can conflict with other non-CYGWIN |
702 |
704 software on your Windows system. |
703 <blockquote> |
705 CYGWIN provides a |
704 <p><em>empty</em> <br /> |
706 <a href="http://cygwin.com/faq/faq.using.html" target="_blank">FAQ</a> for |
705 build everything but no images</p> |
707 known issues and problems, of particular interest is the |
706 |
708 section on |
707 <p><strong><code>all</code></strong> <br /> |
709 <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda" target="_blank"> |
708 build everything including images</p> |
710 BLODA (applications that interfere with CYGWIN)</a>. |
709 |
711 </blockquote> |
710 <p><strong><code>all-conf</code></strong> <br /> |
712 |
711 build all configurations</p> |
713 <h6><a name="msys">MinGW/MSYS</a></h6> |
712 |
714 <blockquote> |
713 <p><strong><code>images</code></strong> <br /> |
715 MinGW ("Minimalist GNU for Windows") is a collection of free Windows |
714 create complete j2sdk and j2re images</p> |
716 specific header files and import libraries combined with GNU toolsets that |
715 |
717 allow one to produce native Windows programs that do not rely on any |
716 <p><strong><code>install</code></strong> <br /> |
718 3rd-party C runtime DLLs. MSYS is a supplement to MinGW which allows building |
717 install the generated images locally, typically in <code>/usr/local</code></p> |
719 applications and programs which rely on traditional UNIX tools to |
718 |
720 be present. Among others this includes tools like <code>bash</code> |
719 <p><strong><code>clean</code></strong> <br /> |
721 and <code>make</code>. |
720 remove all files generated by make, but not those generated by <code>configure</code></p> |
722 See <a href="http://www.mingw.org/wiki/MSYS" target="_blank">MinGW/MSYS</a> |
721 |
723 for more information. |
722 <p><strong><code>dist-clean</code></strong> <br /> |
724 <p> |
723 remove all files generated by both and <code>configure</code> (basically killing the |
725 Like Cygwin, MinGW/MSYS can handle different types of path formats. They |
724 configuration)</p> |
726 are internally converted to paths with forward slashes and drive letters |
725 |
727 <code><drive>:</code> replaced by a virtual |
726 <p><strong><code>help</code></strong> <br /> |
728 directory <code>/<drive></code>. Additionally, MSYS automatically |
727 give some help on using <code>make</code>, including some interesting make targets</p> |
729 detects binaries compiled for the MSYS environment and feeds them with the |
728 </blockquote> |
730 internal, Unix-style path names. If native Windows applications are called |
729 |
731 from within MSYS programs their path arguments are automatically converted |
730 <hr /> |
732 back to Windows style path names with drive letters and backslashes as |
731 |
733 path separators. This may cause problems for Windows applications which |
732 <p><a name="testing"></a></p> |
734 use forward slashes as parameter separator (e.g. <code>cl /nologo /I</code>) |
733 |
735 because MSYS may wrongly <a href="http://mingw.org/wiki/Posix_path_conversion"> |
734 <h2>Testing</h2> |
736 replace such parameters by drive letters</a>. |
735 |
737 </p> |
736 <p>When the build is completed, you should see the generated binaries and |
738 <p> |
737 associated files in the <code>j2sdk-image</code> directory in the output directory. In |
739 In addition to the tools which will be installed |
738 particular, the <code>build/*/images/j2sdk-image/bin</code> directory should contain |
740 by default, you have |
739 executables for the OpenJDK tools and utilities for that configuration. The |
741 to manually install the |
740 testing tool <code>jtreg</code> will be needed and can be found at: <a href="http://openjdk.java.net/jtreg/">the jtreg |
742 <code>msys-zip</code> and |
741 site</a>. The provided regression tests in the |
743 <code>msys-unzip</code> packages. |
742 repositories can be run with the command:</p> |
744 This can be easily done with the MinGW command line installer: |
743 |
745 <blockquote> |
744 <blockquote> |
746 <code>mingw-get.exe install msys-zip</code> |
745 <p><strong><code>cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all</code></strong></p> |
747 <br> |
746 </blockquote> |
748 <code>mingw-get.exe install msys-unzip</code> |
747 |
749 </blockquote> |
748 <hr /> |
750 </blockquote> |
749 |
751 |
750 <p><a name="hints"></a></p> |
752 </blockquote> |
751 |
753 |
752 <h2>Appendix A: Hints and Tips</h2> |
754 <h5><a name="vs2013">Visual Studio 2013 Compilers</a></h5> |
753 |
755 <blockquote> |
754 <p><a name="faq"></a></p> |
756 <p> |
755 |
757 The 32-bit and 64-bit OpenJDK Windows build requires |
756 <h3>FAQ</h3> |
758 Microsoft Visual Studio C++ 2013 (VS2013) Professional |
757 |
759 Edition or Express compiler. |
758 <p><strong>Q:</strong> The <code>generated-configure.sh</code> file looks horrible! How are you going to |
760 The compiler and other tools are expected to reside |
759 edit it? <br /> |
761 in the location defined by the variable |
760 <strong>A:</strong> The <code>generated-configure.sh</code> file is generated (think "compiled") by the |
762 <code>VS120COMNTOOLS</code> which |
761 autoconf tools. The source code is in <code>configure.ac</code> and various .m4 files in |
763 is set by the Microsoft Visual Studio installer. |
762 common/autoconf, which are much more readable.</p> |
764 </p> |
763 |
765 <p> |
764 <p><strong>Q:</strong> Why is the <code>generated-configure.sh</code> file checked in, if it is |
766 Only the C++ part of VS2013 is needed. |
765 generated? <br /> |
767 Try to let the installation go to the default |
766 <strong>A:</strong> If it was not generated, every user would need to have the autoconf |
768 install directory. |
767 tools installed, and re-generate the <code>configure</code> file as the first step. Our |
769 Always reboot your system after installing VS2013. |
768 goal is to minimize the work needed to be done by the user to start building |
770 The system environment variable VS120COMNTOOLS |
769 OpenJDK, and to minimize the number of external dependencies required.</p> |
771 should be |
770 |
772 set in your environment. |
771 <p><strong>Q:</strong> Do you require a specific version of autoconf for regenerating |
773 </p> |
772 <code>generated-configure.sh</code>? <br /> |
774 <p> |
773 <strong>A:</strong> Yes, version 2.69 is required and should be easy enough to aquire on all |
775 Make sure that TMP and TEMP are also set |
774 supported operating systems. The reason for this is to avoid large spurious |
776 in the environment |
775 changes in <code>generated-configure.sh</code>.</p> |
777 and refer to Windows paths that exist, |
776 |
778 like <code>C:\temp</code>, |
777 <p><strong>Q:</strong> How do you regenerate <code>generated-configure.sh</code> after making changes to |
779 not <code>/tmp</code>, not <code>/cygdrive/c/temp</code>, |
778 the input files? <br /> |
780 and not <code>C:/temp</code>. |
779 <strong>A:</strong> Regnerating <code>generated-configure.sh</code> should always be done using the |
781 <code>C:\temp</code> is just an example, |
780 script <code>common/autoconf/autogen.sh</code> to ensure that the correct files get |
782 it is assumed that this area is |
781 updated. This script should also be run after mercurial tries to merge |
783 private to the user, so by default |
782 <code>generated-configure.sh</code> as a merge of the generated file is not guaranteed to |
784 after installs you should |
783 be correct.</p> |
785 see a unique user path in these variables. |
784 |
786 </p> |
785 <p><strong>Q:</strong> What are the files in <code>common/makefiles/support/*</code> for? They look like |
787 </blockquote> |
786 gibberish. <br /> |
788 |
787 <strong>A:</strong> They are a somewhat ugly hack to compensate for command line length |
789 |
788 limitations on certain platforms (Windows, Solaris). Due to a combination of |
790 </blockquote> <!-- Windows --> |
789 limitations in make and the shell, command lines containing too many files will |
791 |
790 not work properly. These helper files are part of an elaborate hack that will |
792 <h4><a name="macosx">Mac OS X</a></h4> |
791 compress the command line in the makefile and then uncompress it safely. We're |
793 <blockquote> |
792 not proud of it, but it does fix the problem. If you have any better |
794 Make sure you get the right XCode version. |
793 suggestions, we're all ears! :-)</p> |
795 </blockquote> <!-- Mac OS X --> |
794 |
796 |
795 <p><strong>Q:</strong> I want to see the output of the commands that make runs, like in the old |
797 </blockquote> |
796 build. How do I do that? <br /> |
798 |
797 <strong>A:</strong> You specify the <code>LOG</code> variable to make. There are several log levels:</p> |
799 <!-- ====================================================== --> |
798 |
800 <hr> |
799 <ul> |
801 <h3><a name="configure">Configure</a></h3> |
800 <li><strong><code>warn</code></strong> -- Default and very quiet.</li> |
802 <blockquote> |
801 <li><strong><code>info</code></strong> -- Shows more progress information than warn.</li> |
803 The basic invocation of the <code>configure</code> script |
802 <li><strong><code>debug</code></strong> -- Echos all command lines and prints all macro calls for |
804 looks like: |
803 compilation definitions.</li> |
805 <blockquote> |
804 <li><strong><code>trace</code></strong> -- Echos all $(shell) command lines as well.</li> |
806 <b><code>bash ./configure [<i>options</i>]</code></b> |
805 </ul> |
807 </blockquote> |
806 |
808 This will create an output directory containing the |
807 <p><strong>Q:</strong> When do I have to re-run <code>configure</code>? <br /> |
809 "configuration" and setup an area for the build result. |
808 <strong>A:</strong> Normally you will run <code>configure</code> only once for creating a |
810 This directory typically looks like: |
809 configuration. You need to re-run configuration only if you want to change any |
811 <blockquote> |
810 configuration options, or if you pull down changes to the <code>configure</code> script.</p> |
812 <b><code>build/linux-x64-normal-server-release</code></b> |
811 |
813 </blockquote> |
812 <p><strong>Q:</strong> I have added a new source file. Do I need to modify the makefiles? <br /> |
814 <code>configure</code> will try to figure out what system you are running on |
813 <strong>A:</strong> Normally, no. If you want to create e.g. a new native library, you will |
815 and where all necessary build components are. |
814 need to modify the makefiles. But for normal file additions or removals, no |
816 If you have all prerequisites for building installed, |
815 changes are needed. There are certan exceptions for some native libraries where |
817 it should find everything. |
816 the source files are spread over many directories which also contain sources |
818 If it fails to detect any component automatically, |
817 for other libraries. In these cases it was simply easier to create include |
819 it will exit and inform you about the problem. |
818 lists rather than excludes.</p> |
820 When this happens, read more below in |
819 |
821 <a href="#configureoptions">the <code>configure</code> options</a>. |
820 <p><strong>Q:</strong> When I run <code>configure --help</code>, I see many strange options, like |
822 <p> |
821 <code>--dvidir</code>. What is this? <br /> |
823 Some examples: |
822 <strong>A:</strong> Configure provides a slew of options by default, to all projects that |
824 </p> |
823 use autoconf. Most of them are not used in OpenJDK, so you can safely ignore |
825 <table border="1"> |
824 them. To list only OpenJDK specific features, use <code>configure --help=short</code> |
826 <thead> |
825 instead.</p> |
827 <tr> |
826 |
828 <th>Description</th> |
827 <p><strong>Q:</strong> <code>configure</code> provides OpenJDK-specific features such as <code>--with- |
829 <th>Configure Command Line</th> |
828 builddeps-server</code> that are not described in this document. What about those? <br /> |
830 </tr> |
829 <strong>A:</strong> Try them out if you like! But be aware that most of these are |
831 </thead> |
830 experimental features. Many of them don't do anything at all at the moment; the |
832 <tbody> |
831 option is just a placeholder. Others depend on pieces of code or infrastructure |
833 <tr> |
832 that is currently not ready for prime time.</p> |
834 <td>Windows 32bit build with freetype specified</td> |
833 |
835 <td> |
834 <p><strong>Q:</strong> How will you make sure you don't break anything? <br /> |
836 <code>bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32</code> |
835 <strong>A:</strong> We have a script that compares the result of the new build system with |
837 </td> |
836 the result of the old. For most part, we aim for (and achieve) byte-by-byte |
838 </tr> |
837 identical output. There are however technical issues with e.g. native binaries, |
839 <tr> |
838 which might differ in a byte-by-byte comparison, even when building twice with |
840 <td>Debug 64bit Build</td> |
839 the old build system. For these, we compare relevant aspects (e.g. the symbol |
841 <td> |
840 table and file size). Note that we still don't have 100% equivalence, but we're |
842 <code>bash ./configure --enable-debug --with-target-bits=64</code> |
841 close.</p> |
843 </td> |
842 |
844 </tr> |
843 <p><strong>Q:</strong> I noticed this thing X in the build that looks very broken by design. |
845 </tbody> |
844 Why don't you fix it? <br /> |
846 </table> |
845 <strong>A:</strong> Our goal is to produce a build output that is as close as technically |
847 |
846 possible to the old build output. If things were weird in the old build, they |
848 <!-- ====================================================== --> |
847 will be weird in the new build. Often, things were weird before due to |
849 <h4><a name="configureoptions">Configure Options</a></h4> |
848 obscurity, but in the new build system the weird stuff comes up to the surface. |
850 <blockquote> |
849 The plan is to attack these things at a later stage, after the new build system |
851 Complete details on all the OpenJDK <code>configure</code> options can |
850 is established.</p> |
852 be seen with: |
851 |
853 <blockquote> |
852 <p><strong>Q:</strong> The code in the new build system is not that well-structured. Will you |
854 <b><code>bash ./configure --help=short</code></b> |
853 fix this? <br /> |
855 </blockquote> |
854 <strong>A:</strong> Yes! The new build system has grown bit by bit as we converted the old |
856 Use <code>-help</code> to see all the <code>configure</code> options |
855 system. When all of the old build system is converted, we can take a step back |
857 available. |
856 and clean up the structure of the new build system. Some of this we plan to do |
858 |
857 before replacing the old build system and some will need to wait until after.</p> |
859 You can generate any number of different configurations, |
858 |
860 e.g. debug, release, 32, 64, etc. |
859 <p><strong>Q:</strong> Is anything able to use the results of the new build's default make |
861 |
860 target? <br /> |
862 Some of the more commonly used <code>configure</code> options are: |
861 <strong>A:</strong> Yes, this is the minimal (or roughly minimal) set of compiled output |
863 |
862 needed for a developer to actually execute the newly built JDK. The idea is |
864 <table border="1"> |
863 that in an incremental development fashion, when doing a normal make, you |
865 <thead> |
864 should only spend time recompiling what's changed (making it purely |
866 <tr> |
865 incremental) and only do the work that's needed to actually run and test your |
867 <th width="300">OpenJDK Configure Option</th> |
866 code. The packaging stuff that is part of the <code>images</code> target is not needed for |
868 <th>Description</th> |
867 a normal developer who wants to test his new code. Even if it's quite fast, |
869 </tr> |
868 it's still unnecessary. We're targeting sub-second incremental rebuilds! ;-) |
870 </thead> |
869 (Or, well, at least single-digit seconds...)</p> |
871 <tbody> |
870 |
872 <tr> |
871 <p><strong>Q:</strong> I usually set a specific environment variable when building, but I can't |
873 <td><b><code>--enable-debug</code></b></td> |
872 find the equivalent in the new build. What should I do? <br /> |
874 <td> |
873 <strong>A:</strong> It might very well be that we have neglected to add support for an |
875 set the debug level to fastdebug (this is a shorthand for |
874 option that was actually used from outside the build system. Email us and we |
876 <code>--with-debug-level=fastdebug</code>) |
875 will add support for it!</p> |
877 </td> |
876 |
878 </tr> |
877 <p><a name="performance"></a></p> |
879 <tr> |
878 |
880 <td><b><code>--with-alsa=</code></b><i>path</i></td> |
879 <h3>Build Performance Tips</h3> |
881 <td> |
880 |
882 select the location of the |
881 <p>Building OpenJDK requires a lot of horsepower. Some of the build tools can be |
883 <a name="alsa">Advanced Linux Sound Architecture (ALSA)</a> |
882 adjusted to utilize more or less of resources such as parallel threads and |
884 <br> |
883 memory. The <code>configure</code> script analyzes your system and selects reasonable |
885 Version 0.9.1 or newer of the ALSA files are |
884 values for such options based on your hardware. If you encounter resource |
886 required for building the OpenJDK on Linux. |
885 problems, such as out of memory conditions, you can modify the detected values |
887 These Linux files are usually available from an "alsa" |
886 with:</p> |
888 of "libasound" |
887 |
889 development package, |
888 <ul> |
890 and it's highly recommended that you try and use |
889 <li><strong><code>--with-num-cores</code></strong> -- number of cores in the build system, e.g. |
891 the package provided by the particular version of Linux that |
890 <code>--with-num-cores=8</code></li> |
892 you are using. |
891 <li><strong><code>--with-memory-size</code></strong> -- memory (in MB) available in the build system, |
893 </td> |
892 e.g. <code>--with-memory-size=1024</code></li> |
894 </tr> |
893 </ul> |
895 <tr> |
894 |
896 <td><b><code>--with-boot-jdk=</code></b><i>path</i></td> |
895 <p>It might also be necessary to specify the JVM arguments passed to the Bootstrap |
897 <td> |
896 JDK, using e.g. <code>--with-boot-jdk-jvmargs="-Xmx8G -enableassertions"</code>. Doing |
898 select the <a href="#bootjdk">Bootstrap JDK</a> |
897 this will override the default JVM arguments passed to the Bootstrap JDK.</p> |
899 </td> |
898 |
900 </tr> |
899 <p>One of the top goals of the new build system is to improve the build |
901 <tr> |
900 performance and decrease the time needed to build. This will soon also apply to |
902 <td><b><code>--with-boot-jdk-jvmargs=</code></b>"<i>args</i>"</td> |
901 the java compilation when the Smart Javac wrapper is fully supported.</p> |
903 <td> |
902 |
904 provide the JVM options to be used to run the |
903 <p>At the end of a successful execution of <code>configure</code>, you will get a performance |
905 <a href="#bootjdk">Bootstrap JDK</a> |
904 summary, indicating how well the build will perform. Here you will also get |
906 </td> |
905 performance hints. If you want to build fast, pay attention to those!</p> |
907 </tr> |
906 |
908 <tr> |
907 <h4>Building with ccache</h4> |
909 <td><b><code>--with-cacerts=</code></b><i>path</i></td> |
908 |
910 <td> |
909 <p>The OpenJDK build supports building with ccache when using gcc or clang. Using |
911 select the path to the cacerts file. |
910 ccache can radically speed up compilation of native code if you often rebuild |
912 <br> |
911 the same sources. Your milage may vary however so we recommend evaluating it |
913 See <a href="http://en.wikipedia.org/wiki/Certificate_Authority" target="_blank"> |
912 for yourself. To enable it, make sure it's on the path and configure with |
914 http://en.wikipedia.org/wiki/Certificate_Authority</a> |
913 <code>--enable-ccache</code>.</p> |
915 for a better understanding of the Certificate Authority (CA). |
914 |
916 A certificates file named "cacerts" |
915 <h4>Building on local disk</h4> |
917 represents a system-wide keystore with CA certificates. |
916 |
918 In JDK and JRE |
917 <p>If you are using network shares, e.g. via NFS, for your source code, make sure |
919 binary bundles, the "cacerts" file contains root CA certificates from |
918 the build directory is situated on local disk. The performance penalty is |
920 several public CAs (e.g., VeriSign, Thawte, and Baltimore). |
919 extremely high for building on a network share, close to unusable.</p> |
921 The source contain a cacerts file |
920 |
922 without CA root certificates. |
921 <h4>Building only one JVM</h4> |
923 Formal JDK builders will need to secure |
922 |
924 permission from each public CA and include the certificates into their |
923 <p>The old build builds multiple JVMs on 32-bit systems (client and server; and on |
925 own custom cacerts file. |
924 Windows kernel as well). In the new build we have changed this default to only |
926 Failure to provide a populated cacerts file |
925 build server when it's available. This improves build times for those not |
927 will result in verification errors of a certificate chain during runtime. |
926 interested in multiple JVMs. To mimic the old behavior on platforms that |
928 By default an empty cacerts file is provided and that should be |
927 support it, use <code>--with-jvm-variants=client,server</code>.</p> |
929 fine for most JDK developers. |
928 |
930 </td> |
929 <h4>Selecting the number of cores to build on</h4> |
931 </tr> |
930 |
932 <tr> |
931 <p>By default, <code>configure</code> will analyze your machine and run the make process in |
933 <td><b><code>--with-cups=</code></b><i>path</i></td> |
932 parallel with as many threads as you have cores. This behavior can be |
934 <td> |
933 overridden, either "permanently" (on a <code>configure</code> basis) using |
935 select the CUPS install location |
934 <code>--with-num-cores=N</code> or for a single build only (on a make basis), using |
936 <br> |
935 <code>make JOBS=N</code>.</p> |
937 The |
936 |
938 <a name="cups">Common UNIX Printing System (CUPS) Headers</a> |
937 <p>If you want to make a slower build just this time, to save some CPU power for |
939 are required for building the |
938 other processes, you can run e.g. <code>make JOBS=2</code>. This will force the makefiles |
940 OpenJDK on Solaris and Linux. |
939 to only run 2 parallel processes, or even <code>make JOBS=1</code> which will disable |
941 The Solaris header files can be obtained by installing |
940 parallelism.</p> |
942 the package <strong>SFWcups</strong> from the Solaris Software |
941 |
943 Companion CD/DVD, these often will be installed into the |
942 <p>If you want to have it the other way round, namely having slow builds default |
944 directory <code>/opt/sfw/cups</code>. |
943 and override with fast if you're impatient, you should call <code>configure</code> with |
945 <br> |
944 <code>--with-num-cores=2</code>, making 2 the default. If you want to run with more cores, |
946 The CUPS header files can always be downloaded from |
945 run <code>make JOBS=8</code></p> |
947 <a href="http://www.cups.org" target="_blank">www.cups.org</a>. |
946 |
948 </td> |
947 <p><a name="troubleshooting"></a></p> |
949 </tr> |
948 |
950 <tr> |
949 <h3>Troubleshooting</h3> |
951 <td><b><code>--with-cups-include=</code></b><i>path</i></td> |
950 |
952 <td> |
951 <h4>Solving build problems</h4> |
953 select the CUPS include directory location |
952 |
954 </td> |
953 <p>If the build fails (and it's not due to a compilation error in a source file |
955 </tr> |
954 you've changed), the first thing you should do is to re-run the build with more |
956 <tr> |
955 verbosity. Do this by adding <code>LOG=debug</code> to your make command line.</p> |
957 <td><b><code>--with-debug-level=</code></b><i>level</i></td> |
956 |
958 <td> |
957 <p>The build log (with both stdout and stderr intermingled, basically the same as |
959 select the debug information level of release, |
958 you see on your console) can be found as <code>build.log</code> in your build directory.</p> |
960 fastdebug, or slowdebug |
959 |
961 </td> |
960 <p>You can ask for help on build problems with the new build system on either the |
962 </tr> |
961 <a href="http://mail.openjdk.java.net/mailman/listinfo/build-dev">build-dev</a> or the |
963 <tr> |
962 <a href="http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev">build-infra-dev</a> |
964 <td><b><code>--with-dev-kit=</code></b><i>path</i></td> |
963 mailing lists. Please include the relevant parts of the build log.</p> |
965 <td> |
964 |
966 select location of the compiler install or |
965 <p>A build can fail for any number of reasons. Most failures are a result of |
967 developer install location |
966 trying to build in an environment in which all the pre-build requirements have |
968 </td> |
967 not been met. The first step in troubleshooting a build failure is to recheck |
969 </tr> |
968 that you have satisfied all the pre-build requirements for your platform. |
970 <tr> |
969 Scanning the <code>configure</code> log is a good first step, making sure that what it |
971 <td><b><code>--with-freetype=</code></b><i>path</i></td> |
970 found makes sense for your system. Look for strange error messages or any |
972 <td> |
971 difficulties that <code>configure</code> had in finding things.</p> |
973 select the freetype files to use. |
972 |
974 <br> |
973 <p>Some of the more common problems with builds are briefly described below, with |
975 Expecting the |
974 suggestions for remedies.</p> |
976 <a name="freetype">freetype</a> libraries under |
975 |
977 <code>lib/</code> and the |
976 <ul> |
978 headers under <code>include/</code>. |
977 <li><p><strong>Corrupted Bundles on Windows:</strong> <br /> |
979 <br> |
978 Some virus scanning software has been known to corrupt the downloading of |
980 Version 2.3 or newer of FreeType is required. |
979 zip bundles. It may be necessary to disable the 'on access' or 'real time' |
981 On Unix systems required files can be available as part of your |
980 virus scanning features to prevent this corruption. This type of 'real time' |
982 distribution (while you still may need to upgrade them). |
981 virus scanning can also slow down the build process significantly. |
983 Note that you need development version of package that |
982 Temporarily disabling the feature, or excluding the build output directory |
984 includes both the FreeType library and header files. |
983 may be necessary to get correct and faster builds.</p></li> |
985 <br> |
984 <li><p><strong>Slow Builds:</strong> <br /> |
986 You can always download latest FreeType version from the |
985 If your build machine seems to be overloaded from too many simultaneous C++ |
987 <a href="http://www.freetype.org" target="_blank">FreeType website</a>. |
986 compiles, try setting the <code>JOBS=1</code> on the <code>make</code> command line. Then try |
988 <br> |
987 increasing the count slowly to an acceptable level for your system. Also:</p> |
989 Building the freetype 2 libraries from scratch is also possible, |
988 |
990 however on Windows refer to the |
989 <p>Creating the javadocs can be very slow, if you are running javadoc, consider |
991 <a href="http://freetype.freedesktop.org/wiki/FreeType_DLL"> |
990 skipping that step.</p> |
992 Windows FreeType DLL build instructions</a>. |
991 |
993 <br> |
992 <p>Faster CPUs, more RAM, and a faster DISK usually helps. The VM build tends |
994 Note that by default FreeType is built with byte code hinting |
993 to be CPU intensive (many C++ compiles), and the rest of the JDK will often |
995 support disabled due to licensing restrictions. |
994 be disk intensive.</p> |
996 In this case, text appearance and metrics are expected to |
995 |
997 differ from Sun's official JDK build. |
996 <p>Faster compiles are possible using a tool called |
998 See |
997 <a href="http://ccache.samba.org/">ccache</a>.</p></li> |
999 <a href="http://freetype.sourceforge.net/freetype2/index.html"> |
998 <li><p><strong>File time issues:</strong> <br /> |
1000 the SourceForge FreeType2 Home Page |
999 If you see warnings that refer to file time stamps, e.g.</p> |
1001 </a> |
1000 |
1002 for more information. |
1001 <blockquote> |
1003 </td> |
1002 <p><em>Warning message:</em> <code>File 'xxx' has modification time in the future.</code> <br /> |
1004 </tr> |
1003 <em>Warning message:</em> <code>Clock skew detected. Your build may be incomplete.</code></p> |
1005 <tr> |
1004 </blockquote> |
1006 <td><b><code>--with-import-hotspot=</code></b><i>path</i></td> |
1005 |
1007 <td> |
1006 <p>These warnings can occur when the clock on the build machine is out of sync |
1008 select the location to find hotspot |
1007 with the timestamps on the source files. Other errors, apparently unrelated |
1009 binaries from a previous build to avoid building |
1008 but in fact caused by the clock skew, can occur along with the clock skew |
1010 hotspot |
1009 warnings. These secondary errors may tend to obscure the fact that the true |
1011 </td> |
1010 root cause of the problem is an out-of-sync clock.</p> |
1012 </tr> |
1011 |
1013 <tr> |
1012 <p>If you see these warnings, reset the clock on the build machine, run |
1014 <td><b><code>--with-target-bits=</code></b><i>arg</i></td> |
1013 "<code>gmake clobber</code>" or delete the directory containing the build output, and |
1015 <td> |
1014 restart the build from the beginning.</p></li> |
1016 select 32 or 64 bit build |
1015 <li><p><strong>Error message: <code>Trouble writing out table to disk</code></strong> <br /> |
1017 </td> |
1016 Increase the amount of swap space on your build machine. This could be |
1018 </tr> |
1017 caused by overloading the system and it may be necessary to use:</p> |
1019 <tr> |
1018 |
1020 <td><b><code>--with-jvm-variants=</code></b><i>variants</i></td> |
1019 <blockquote> |
1021 <td> |
1020 <p><code>make JOBS=1</code></p> |
1022 select the JVM variants to build from, comma |
1021 </blockquote> |
1023 separated list that can include: |
1022 |
1024 server, client, kernel, zero and zeroshark |
1023 <p>to reduce the load on the system.</p></li> |
1025 </td> |
1024 <li><p><strong>Error Message: <code>libstdc++ not found</code>:</strong> <br /> |
1026 </tr> |
1025 This is caused by a missing libstdc++.a library. This is installed as part |
1027 <tr> |
1026 of a specific package (e.g. libstdc++.so.devel.386). By default some 64-bit |
1028 <td><b><code>--with-memory-size=</code></b><i>size</i></td> |
1027 Linux versions (e.g. Fedora) only install the 64-bit version of the |
1029 <td> |
1028 libstdc++ package. Various parts of the JDK build require a static link of |
1030 select the RAM size that GNU make will think |
1029 the C++ runtime libraries to allow for maximum portability of the built |
1031 this system has |
1030 images.</p></li> |
1032 </td> |
1031 <li><p><strong>Linux Error Message: <code>cannot restore segment prot after reloc</code></strong> <br /> |
1033 </tr> |
1032 This is probably an issue with SELinux (See <a href="http://en.wikipedia.org/wiki/SELinux">SELinux on |
1034 <tr> |
1033 Wikipedia</a>). Parts of the VM is built |
1035 <td><a name="msvcrNN"><b><code>--with-msvcr-dll=</code></b><i>path</i></a></td> |
1034 without the <code>-fPIC</code> for performance reasons.</p> |
1036 <td> |
1035 |
1037 select the <code>msvcr100.dll</code> |
1036 <p>To completely disable SELinux:</p> |
1038 file to include in the |
1037 |
1039 Windows builds (C/C++ runtime library for |
1038 <ol> |
1040 Visual Studio). |
1039 <li><code>$ su root</code></li> |
1041 <br> |
1040 <li><code># system-config-securitylevel</code></li> |
1042 This is usually picked up automatically |
1041 <li><code>In the window that appears, select the SELinux tab</code></li> |
1043 from the redist |
1042 <li><code>Disable SELinux</code></li> |
1044 directories of Visual Studio 2013. |
1043 </ol> |
1045 </td> |
1044 |
1046 </tr> |
1045 <p>Alternatively, instead of completely disabling it you could disable just |
1047 <tr> |
1046 this one check.</p> |
1048 <td><b><code>--with-num-cores=</code></b><i>cores</i></td> |
1047 |
1049 <td> |
1048 <ol> |
1050 select the number of cores to use (processor |
1049 <li>Select System->Administration->SELinux Management</li> |
1051 count or CPU count) |
1050 <li>In the SELinux Management Tool which appears, select "Boolean" from the |
1052 </td> |
1051 menu on the left</li> |
1053 </tr> |
1052 <li>Expand the "Memory Protection" group</li> |
1054 <tr> |
1053 <li>Check the first item, labeled "Allow all unconfined executables to use |
1055 <td><b><code>--with-x=</code></b><i>path</i></td> |
1054 libraries requiring text relocation ..."</li> |
1056 <td> |
1055 </ol></li> |
1057 select the location of the X11 and xrender files. |
1056 <li><p><strong>Windows Error Messages:</strong> <br /> |
1058 <br> |
1057 <code>*** fatal error - couldn't allocate heap, ...</code> <br /> |
1059 The |
1058 <code>rm fails with "Directory not empty"</code> <br /> |
1060 <a name="xrender">XRender Extension Headers</a> |
1059 <code>unzip fails with "cannot create ... Permission denied"</code> <br /> |
1061 are required for building the |
1060 <code>unzip fails with "cannot create ... Error 50"</code></p> |
1062 OpenJDK on Solaris and Linux. |
1061 |
1063 <br> |
1062 <p>The CYGWIN software can conflict with other non-CYGWIN software. See the |
1064 The Linux header files are usually available from a "Xrender" |
1063 CYGWIN FAQ section on <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda">BLODA (applications that interfere with |
1065 development package, it's recommended that you try and use |
1064 CYGWIN)</a>.</p></li> |
1066 the package provided by the particular distribution of Linux that |
1065 <li><p><strong>Windows Error Message: <code>spawn failed</code></strong> <br /> |
1067 you are using. |
1066 Try rebooting the system, or there could be some kind of issue with the disk |
1068 <br> |
1067 or disk partition being used. Sometimes it comes with a "Permission Denied" |
1069 The Solaris XRender header files is |
1068 message.</p></li> |
1070 included with the other X11 header files |
1069 </ul> |
1071 in the package <strong>SFWxwinc</strong> |
1070 |
1072 on new enough versions of |
1071 <hr /> |
1073 Solaris and will be installed in |
1072 |
1074 <code>/usr/X11/include/X11/extensions/Xrender.h</code> or |
1073 <p><a name="gmake"></a></p> |
1075 <code>/usr/openwin/share/include/X11/extensions/Xrender.h</code> |
1074 |
1076 </td> |
1075 <h2>Appendix B: GNU make</h2> |
1077 </tr> |
1076 |
1078 </tbody> |
1077 <p>The Makefiles in the OpenJDK are only valid when used with the GNU version of |
1079 </table> |
1078 the utility command <code>make</code> (usually called <code>gmake</code> on Solaris). A few notes |
1080 </blockquote> |
1079 about using GNU make:</p> |
1081 |
1080 |
1082 </blockquote> |
1081 <ul> |
1083 |
1082 <li>You need GNU make version 3.81 or newer. On Windows 4.0 or newer is |
1084 <!-- ====================================================== --> |
1083 recommended. If the GNU make utility on your systems is not of a suitable |
1085 <hr> |
1084 version, see "<a href="#buildgmake">Building GNU make</a>".</li> |
1086 <h3><a name="make">Make</a></h3> |
1085 <li>Place the location of the GNU make binary in the <code>PATH</code>.</li> |
1087 <blockquote> |
1086 <li><strong>Solaris:</strong> Do NOT use <code>/usr/bin/make</code> on Solaris. If your Solaris system |
1088 The basic invocation of the <code>make</code> utility |
1087 has the software from the Solaris Developer Companion CD installed, you |
1089 looks like: |
1088 should try and use <code>gmake</code> which will be located in either the <code>/usr/bin</code>, |
1090 <blockquote> |
1089 <code>/opt/sfw/bin</code> or <code>/usr/sfw/bin</code> directory.</li> |
1091 <b><code>make all</code></b> |
1090 <li><strong>Windows:</strong> Make sure you start your build inside a bash shell.</li> |
1092 </blockquote> |
1091 <li><strong>Mac OS X:</strong> The XCode "command line tools" must be installed on your Mac.</li> |
1093 This will start the build to the output directory containing the |
1092 </ul> |
1094 "configuration" that was created by the <code>configure</code> |
1093 |
1095 script. Run <code>make help</code> for more information on |
1094 <p>Information on GNU make, and access to ftp download sites, are available on the |
1096 the available targets. |
1095 <a href="http://www.gnu.org/software/make/make.html">GNU make web site </a>. The latest |
1097 <br> |
1096 source to GNU make is available at |
1098 There are some of the make targets that |
1097 <a href="http://ftp.gnu.org/pub/gnu/make/">ftp.gnu.org/pub/gnu/make/</a>.</p> |
1099 are of general interest: |
1098 |
1100 <table border="1"> |
1099 <p><a name="buildgmake"></a></p> |
1101 <thead> |
1100 |
1102 <tr> |
1101 <h3>Building GNU make</h3> |
1103 <th>Make Target</th> |
1102 |
1104 <th>Description</th> |
1103 <p>First step is to get the GNU make 3.81 or newer source from |
1105 </tr> |
1104 <a href="http://ftp.gnu.org/pub/gnu/make/">ftp.gnu.org/pub/gnu/make/</a>. Building is a |
1106 </thead> |
1105 little different depending on the OS but is basically done with:</p> |
1107 <tbody> |
1106 |
1108 <tr> |
1107 <pre><code> bash ./configure |
1109 <td><i>empty</i></td> |
1108 make |
1110 <td>build everything but no images</td> |
1109 </code></pre> |
1111 </tr> |
1110 |
1112 <tr> |
1111 <hr /> |
1113 <td><b><code>all</code></b></td> |
1112 |
1114 <td>build everything including images</td> |
1113 <p><a name="buildenvironments"></a></p> |
1115 </tr> |
1114 |
1116 <tr> |
1115 <h2>Appendix C: Build Environments</h2> |
1117 <td><b><code>all-conf</code></b></td> |
1116 |
1118 <td>build all configurations</td> |
1117 <h3>Minimum Build Environments</h3> |
1119 </tr> |
1118 |
1120 <tr> |
1119 <p>This file often describes specific requirements for what we call the "minimum |
1121 <td><b><code>images</code></b></td> |
1120 build environments" (MBE) for this specific release of the JDK. What is listed |
1122 <td>create complete j2sdk and j2re images</td> |
1121 below is what the Oracle Release Engineering Team will use to build the Oracle |
1123 </tr> |
1122 JDK product. Building with the MBE will hopefully generate the most compatible |
1124 <tr> |
1123 bits that install on, and run correctly on, the most variations of the same |
1125 <td><b><code>install</code></b></td> |
1124 base OS and hardware architecture. In some cases, these represent what is often |
1126 <td>install the generated images locally, |
1125 called the least common denominator, but each Operating System has different |
1127 typically in <code>/usr/local</code></td> |
1126 aspects to it.</p> |
1128 </tr> |
1127 |
1129 <tr> |
1128 <p>In all cases, the Bootstrap JDK version minimum is critical, we cannot |
1130 <td><b><code>clean</code></b></td> |
1129 guarantee builds will work with older Bootstrap JDK's. Also in all cases, more |
1131 <td>remove all files generated by make, |
1130 RAM and more processors is better, the minimums listed below are simply |
1132 but not those generated by <code>configure</code></td> |
1131 recommendations.</p> |
1133 </tr> |
1132 |
1134 <tr> |
1133 <p>With Solaris and Mac OS X, the version listed below is the oldest release we |
1135 <td><b><code>dist-clean</code></b></td> |
1134 can guarantee builds and works, and the specific version of the compilers used |
1136 <td>remove all files generated by both |
1135 could be critical.</p> |
1137 and <code>configure</code> (basically killing the configuration)</td> |
1136 |
1138 </tr> |
1137 <p>With Windows the critical aspect is the Visual Studio compiler used, which due |
1139 <tr> |
1138 to it's runtime, generally dictates what Windows systems can do the builds and |
1140 <td><b><code>help</code></b></td> |
1139 where the resulting bits can be used.</p> |
1141 <td>give some help on using <code>make</code>, |
1140 |
1142 including some interesting make targets</td> |
1141 <p><strong>NOTE: We expect a change here off these older Windows OS releases and to a |
1143 </tr> |
1142 'less older' one, probably Windows 2008R2 X64.</strong></p> |
1144 </tbody> |
1143 |
1145 </table> |
1144 <p>With Linux, it was just a matter of picking a stable distribution that is a |
1146 </blockquote> |
1145 good representative for Linux in general.</p> |
1147 </blockquote> |
1146 |
1148 |
1147 <p><strong>NOTE: We expect a change here from Fedora 9 to something else, but it has not |
1149 <!-- ====================================================== --> |
1148 been completely determined yet, possibly Ubuntu 12.04 X64, unbiased community |
1150 <hr> |
1149 feedback would be welcome on what a good choice would be here.</strong></p> |
1151 <h2><a name="testing">Testing</a></h2> |
1150 |
1152 <blockquote> |
1151 <p>It is understood that most developers will NOT be using these specific |
1153 When the build is completed, you should see the generated |
1152 versions, and in fact creating these specific versions may be difficult due to |
1154 binaries and associated files in the <code>j2sdk-image</code> |
1153 the age of some of this software. It is expected that developers are more often |
1155 directory in the output directory. |
1154 using the more recent releases and distributions of these operating systems.</p> |
1156 In particular, the |
1155 |
1157 <code>build/<i>*</i>/images/j2sdk-image/bin</code> |
1156 <p>Compilation problems with newer or different C/C++ compilers is a common |
1158 directory should contain executables for the |
1157 problem. Similarly, compilation problems related to changes to the |
1159 OpenJDK tools and utilities for that configuration. |
1158 <code>/usr/include</code> or system header files is also a common problem with older, |
1160 The testing tool <code>jtreg</code> will be needed |
1159 newer, or unreleased OS versions. Please report these types of problems as bugs |
1161 and can be found at: |
1160 so that they can be dealt with accordingly.</p> |
1162 <a href="http://openjdk.java.net/jtreg/" target="_blank"> |
1161 |
1163 the jtreg site</a>. |
1162 <blockquote> |
1164 The provided regression tests in the repositories |
1163 <p><table border="1"> |
1165 can be run with the command: |
1164 <thead> |
1166 <blockquote> |
1165 <tr> |
1167 <code><b>cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all</b></code> |
1166 <th>Base OS and Architecture</th> |
1168 </blockquote> |
1167 <th>OS</th> |
1169 </blockquote> |
1168 <th>C/C++ Compiler</th> |
1170 |
1169 <th>Bootstrap JDK</th> |
1171 <!-- ====================================================== --> |
1170 <th>Processors</th> |
1172 <!-- ====================================================== --> |
1171 <th>RAM Minimum</th> |
1173 <!-- ====================================================== --> |
1172 <th>DISK Needs</th> |
1174 <!-- ====================================================== --> |
1173 </tr> |
1175 <!-- ====================================================== --> |
1174 </thead> |
1176 <!-- ====================================================== --> |
1175 <tbody> |
1177 <!-- ====================================================== --> |
1176 <tr> |
1178 <!-- ====================================================== --> |
1177 <td>Linux X86 (32-bit) and X64 (64-bit)</td> |
1179 <!-- ====================================================== --> |
1178 <td>Oracle Enterprise Linux 6.4</td> |
1180 |
1179 <td>gcc 4.8.2 </td> |
1181 <!-- ====================================================== --> |
1180 <td>JDK 8</td> |
1182 <hr> |
1181 <td>2 or more</td> |
1183 <h2><a name="hints">Appendix A: Hints and Tips</a></h2> |
1182 <td>1 GB</td> |
1184 <blockquote> |
1183 <td>6 GB</td> |
1185 |
1184 </tr> |
1186 <h3><a name="faq">FAQ</a></h3> |
1185 <tr> |
1187 <blockquote> |
1186 <td>Solaris SPARCV9 (64-bit)</td> |
1188 |
1187 <td>Solaris 10 Update 10</td> |
1189 <p> |
1188 <td>Studio 12 Update 3 + patches</td> |
1190 <b>Q:</b> The <code>generated-configure.sh</code> file looks horrible! |
1189 <td>JDK 8</td> |
1191 How are you going to edit it? |
1190 <td>4 or more</td> |
1192 <br> |
1191 <td>4 GB</td> |
1193 <b>A:</b> The <code>generated-configure.sh</code> file is generated (think |
1192 <td>8 GB</td> |
1194 "compiled") by the autoconf tools. The source code is |
1193 </tr> |
1195 in <code>configure.ac</code> and various .m4 files in common/autoconf, |
1194 <tr> |
1196 which are much more readable. |
1195 <td>Solaris X64 (64-bit)</td> |
1197 </p> |
1196 <td>Solaris 10 Update 10</td> |
1198 |
1197 <td>Studio 12 Update 3 + patches</td> |
1199 <p> |
1198 <td>JDK 8</td> |
1200 <b>Q:</b> |
1199 <td>4 or more</td> |
1201 Why is the <code>generated-configure.sh</code> file checked in, |
1200 <td>4 GB</td> |
1202 if it is generated? |
1201 <td>8 GB</td> |
1203 <br> |
1202 </tr> |
1204 <b>A:</b> |
1203 <tr> |
1205 If it was not generated, every user would need to have the autoconf |
1204 <td>Windows X86 (32-bit)</td> |
1206 tools installed, and re-generate the <code>configure</code> file |
1205 <td>Windows Server 2012 R2 x64</td> |
1207 as the first step. |
1206 <td>Microsoft Visual Studio C++ 2013 Professional Edition</td> |
1208 Our goal is to minimize the work needed to be done by the user |
1207 <td>JDK 8</td> |
1209 to start building OpenJDK, and to minimize |
1208 <td>2 or more</td> |
1210 the number of external dependencies required. |
1209 <td>2 GB</td> |
1211 </p> |
1210 <td>6 GB</td> |
1212 |
1211 </tr> |
1213 <p> |
1212 <tr> |
1214 <b>Q:</b> |
1213 <td>Windows X64 (64-bit)</td> |
1215 Do you require a specific version of autoconf for regenerating |
1214 <td>Windows Server 2012 R2 x64</td> |
1216 <code>generated-configure.sh</code>? |
1215 <td>Microsoft Visual Studio C++ 2013 Professional Edition</td> |
1217 <br> |
1216 <td>JDK 8</td> |
1218 <b>A:</b> |
1217 <td>2 or more</td> |
1219 Yes, version 2.69 is required and should be easy |
1218 <td>2 GB</td> |
1220 enough to aquire on all supported operating |
1219 <td>6 GB</td> |
1221 systems. The reason for this is to avoid |
1220 </tr> |
1222 large spurious changes in <code>generated-configure.sh</code>. |
1221 <tr> |
1223 </p> |
1222 <td>Mac OS X X64 (64-bit)</td> |
1224 |
1223 <td>Mac OS X 10.9 "Mavericks"</td> |
1225 <p> |
1224 <td>XCode 5.1.1 or newer</td> |
1226 <b>Q:</b> |
1225 <td>JDK 8</td> |
1227 How do you regenerate <code>generated-configure.sh</code> |
1226 <td>2 or more</td> |
1228 after making changes to the input files? |
1227 <td>4 GB</td> |
1229 <br> |
1228 <td>6 GB</td> |
1230 <b>A:</b> |
1229 </tr> |
1231 Regnerating <code>generated-configure.sh</code> |
1230 </tbody> |
1232 should always be done using the |
1231 </table></p> |
1233 script <code>common/autoconf/autogen.sh</code> to |
1232 </blockquote> |
1234 ensure that the correct files get updated. This |
1233 |
1235 script should also be run after mercurial tries to |
1234 <hr /> |
1236 merge <code>generated-configure.sh</code> as a |
1235 |
1237 merge of the generated file is not guaranteed to |
1236 <p><a name="SDBE"></a></p> |
1238 be correct. |
1237 |
1239 </p> |
1238 <h3>Specific Developer Build Environments</h3> |
1240 |
1239 |
1241 <p> |
1240 <p>We won't be listing all the possible environments, but we will try to provide |
1242 <b>Q:</b> |
1241 what information we have available to us.</p> |
1243 What are the files in <code>common/makefiles/support/*</code> for? |
1242 |
1244 They look like gibberish. |
1243 <p><strong>NOTE: The community can help out by updating this part of the document.</strong></p> |
1245 <br> |
1244 |
1246 <b>A:</b> |
1245 <h4>Fedora</h4> |
1247 They are a somewhat ugly hack to compensate for command line length |
1246 |
1248 limitations on certain platforms (Windows, Solaris). |
1247 <p>After installing the latest <a href="http://fedoraproject.org">Fedora</a> you need to |
1249 Due to a combination of limitations in make and the shell, |
1248 install several build dependencies. The simplest way to do it is to execute the |
1250 command lines containing too many files will not work properly. |
1249 following commands as user <code>root</code>:</p> |
1251 These |
1250 |
1252 helper files are part of an elaborate hack that will compress the |
1251 <pre><code> yum-builddep java-1.7.0-openjdk |
1253 command line in the makefile and then uncompress it safely. |
1252 yum install gcc gcc-c++ |
1254 We're |
1253 </code></pre> |
1255 not proud of it, but it does fix the problem. |
1254 |
1256 If you have any better suggestions, we're all ears! :-) |
1255 <p>In addition, it's necessary to set a few environment variables for the build:</p> |
1257 </p> |
1256 |
1258 |
1257 <pre><code> export LANG=C |
1259 <p> |
1258 export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}" |
1260 <b>Q:</b> |
1259 </code></pre> |
1261 I want to see the output of the commands that make runs, |
1260 |
1262 like in the old build. How do I do that? |
1261 <h4>CentOS 5.5</h4> |
1263 <br> |
1262 |
1264 <b>A:</b> |
1263 <p>After installing <a href="http://www.centos.org/">CentOS 5.5</a> you need to make sure you |
1265 You specify the <code>LOG</code> variable to make. There are |
1264 have the following Development bundles installed:</p> |
1266 several log levels: |
1265 |
1267 </p> |
1266 <ul> |
1268 <blockquote> |
1267 <li>Development Libraries</li> |
1269 <ul> |
1268 <li>Development Tools</li> |
1270 <li> |
1269 <li>Java Development</li> |
1271 <b><code>warn</code></b> — Default and very quiet. |
1270 <li>X Software Development (Including XFree86-devel)</li> |
1272 </li> |
1271 </ul> |
1273 <li> |
1272 |
1274 <b><code>info</code></b> — Shows more progress information |
1273 <p>Plus the following packages:</p> |
1275 than warn. |
1274 |
1276 </li> |
1275 <ul> |
1277 <li> |
1276 <li>cups devel: Cups Development Package</li> |
1278 <b><code>debug</code></b> — Echos all command lines and |
1277 <li>alsa devel: Alsa Development Package</li> |
1279 prints all macro calls for compilation definitions. |
1278 <li>Xi devel: libXi.so Development Package</li> |
1280 </li> |
1279 </ul> |
1281 <li> |
1280 |
1282 <b><code>trace</code></b> — Echos all $(shell) command |
1281 <p>The freetype 2.3 packages don't seem to be available, but the freetype 2.3 |
1283 lines as well. |
1282 sources can be downloaded, built, and installed easily enough from <a href="http://downloads.sourceforge.net/freetype">the |
1284 </li> |
1283 freetype site</a>. Build and install |
1285 </ul> |
1284 with something like:</p> |
1286 </blockquote> |
1285 |
1287 |
1286 <pre><code> bash ./configure |
1288 <p> |
1287 make |
1289 <b>Q:</b> |
1288 sudo -u root make install |
1290 When do I have to re-run <code>configure</code>? |
1289 </code></pre> |
1291 <br> |
1290 |
1292 <b>A:</b> |
1291 <p>Mercurial packages could not be found easily, but a Google search should find |
1293 Normally you will run <code>configure</code> only once for creating a |
1292 ones, and they usually include Python if it's needed.</p> |
1294 configuration. |
1293 |
1295 You need to re-run configuration only if you want to change any |
1294 <h4>Debian 5.0 (Lenny)</h4> |
1296 configuration options, |
1295 |
1297 or if you pull down changes to the <code>configure</code> script. |
1296 <p>After installing <a href="http://debian.org">Debian</a> 5 you need to install several |
1298 </p> |
1297 build dependencies. The simplest way to install the build dependencies is to |
1299 |
1298 execute the following commands as user <code>root</code>:</p> |
1300 <p> |
1299 |
1301 <b>Q:</b> |
1300 <pre><code> aptitude build-dep openjdk-7 |
1302 I have added a new source file. Do I need to modify the makefiles? |
1301 aptitude install openjdk-7-jdk libmotif-dev |
1303 <br> |
1302 </code></pre> |
1304 <b>A:</b> |
1303 |
1305 Normally, no. If you want to create e.g. a new native |
1304 <p>In addition, it's necessary to set a few environment variables for the build:</p> |
1306 library, |
1305 |
1307 you will need to modify the makefiles. But for normal file |
1306 <pre><code> export LANG=C |
1308 additions or removals, no changes are needed. There are certan |
1307 export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}" |
1309 exceptions for some native libraries where the source files are spread |
1308 </code></pre> |
1310 over many directories which also contain sources for other |
1309 |
1311 libraries. In these cases it was simply easier to create include lists |
1310 <h4>Ubuntu 12.04</h4> |
1312 rather than excludes. |
1311 |
1313 </p> |
1312 <p>After installing <a href="http://ubuntu.org">Ubuntu</a> 12.04 you need to install several |
1314 |
1313 build dependencies. The simplest way to do it is to execute the following |
1315 <p> |
1314 commands:</p> |
1316 <b>Q:</b> |
1315 |
1317 When I run <code>configure --help</code>, I see many strange options, |
1316 <pre><code> sudo aptitude build-dep openjdk-7 |
1318 like <code>--dvidir</code>. What is this? |
1317 sudo aptitude install openjdk-7-jdk |
1319 <br> |
1318 </code></pre> |
1320 <b>A:</b> |
1319 |
1321 Configure provides a slew of options by default, to all projects |
1320 <p>In addition, it's necessary to set a few environment variables for the build:</p> |
1322 that use autoconf. Most of them are not used in OpenJDK, |
1321 |
1323 so you can safely ignore them. To list only OpenJDK specific features, |
1322 <pre><code> export LANG=C |
1324 use <code>configure --help=short</code> instead. |
1323 export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}" |
1325 </p> |
1324 </code></pre> |
1326 |
1325 |
1327 <p> |
1326 <h4>OpenSUSE 11.1</h4> |
1328 <b>Q:</b> |
1327 |
1329 <code>configure</code> provides OpenJDK-specific features such as |
1328 <p>After installing <a href="http://opensuse.org">OpenSUSE</a> 11.1 you need to install |
1330 <code>--with-builddeps-server</code> that are not |
1329 several build dependencies. The simplest way to install the build dependencies |
1331 described in this document. What about those? |
1330 is to execute the following commands:</p> |
1332 <br> |
1331 |
1333 <b>A:</b> |
1332 <pre><code> sudo zypper source-install -d java-1_7_0-openjdk |
1334 Try them out if you like! But be aware that most of these are |
1333 sudo zypper install make |
1335 experimental features. |
1334 </code></pre> |
1336 Many of them don't do anything at all at the moment; the option |
1335 |
1337 is just a placeholder. Others depend on |
1336 <p>In addition, it is necessary to set a few environment variables for the build:</p> |
1338 pieces of code or infrastructure that is currently |
1337 |
1339 not ready for prime time. |
1338 <pre><code> export LANG=C |
1340 </p> |
1339 export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}" |
1341 |
1340 </code></pre> |
1342 <p> |
1341 |
1343 <b>Q:</b> |
1342 <p>Finally, you need to unset the <code>JAVA_HOME</code> environment variable:</p> |
1344 How will you make sure you don't break anything? |
1343 |
1345 <br> |
1344 <pre><code> export -n JAVA_HOME` |
1346 <b>A:</b> |
1345 </code></pre> |
1347 We have a script that compares the result of the new build system |
1346 |
1348 with the result of the old. For most part, we aim for (and achieve) |
1347 <h4>Mandriva Linux One 2009 Spring</h4> |
1349 byte-by-byte identical output. There are however technical issues |
1348 |
1350 with e.g. native binaries, which might differ in a byte-by-byte |
1349 <p>After installing <a href="http://mandriva.org">Mandriva</a> Linux One 2009 Spring you need |
1351 comparison, even |
1350 to install several build dependencies. The simplest way to install the build |
1352 when building twice with the old build system. |
1351 dependencies is to execute the following commands as user <code>root</code>:</p> |
1353 For these, we compare relevant aspects |
1352 |
1354 (e.g. the symbol table and file size). |
1353 <pre><code> urpmi java-1.7.0-openjdk-devel make gcc gcc-c++ freetype-devel zip unzip |
1355 Note that we still don't have 100% |
1354 libcups2-devel libxrender1-devel libalsa2-devel libstc++-static-devel |
1356 equivalence, but we're close. |
1355 libxtst6-devel libxi-devel |
1357 </p> |
1356 </code></pre> |
1358 |
1357 |
1359 <p> |
1358 <p>In addition, it is necessary to set a few environment variables for the build:</p> |
1360 <b>Q:</b> |
1359 |
1361 I noticed this thing X in the build that looks very broken by design. |
1360 <pre><code> export LANG=C |
1362 Why don't you fix it? |
1361 export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}" |
1363 <br> |
1362 </code></pre> |
1364 <b>A:</b> |
1363 |
1365 Our goal is to produce a build output that is as close as |
1364 <h4>OpenSolaris 2009.06</h4> |
1366 technically possible to the old build output. |
1365 |
1367 If things were weird in the old build, |
1366 <p>After installing <a href="http://opensolaris.org">OpenSolaris</a> 2009.06 you need to |
1368 they will be weird in the new build. |
1367 install several build dependencies. The simplest way to install the build |
1369 Often, things were weird before due to obscurity, |
1368 dependencies is to execute the following commands:</p> |
1370 but in the new build system the weird stuff comes up to the surface. |
1369 |
1371 The plan is to attack these things at a later stage, |
1370 <pre><code> pfexec pkg install SUNWgmake SUNWj7dev sunstudioexpress SUNWcups SUNWzip |
1372 after the new build system is established. |
1371 SUNWunzip SUNWxwhl SUNWxorg-headers SUNWaudh SUNWfreetype2 |
1373 </p> |
1372 </code></pre> |
1374 |
1373 |
1375 <p> |
1374 <p>In addition, it is necessary to set a few environment variables for the build:</p> |
1376 <b>Q:</b> |
1375 |
1377 The code in the new build system is not that well-structured. |
1376 <pre><code> export LANG=C |
1378 Will you fix this? |
1377 export PATH="/opt/SunStudioExpress/bin:${PATH}" |
1379 <br> |
1378 </code></pre> |
1380 <b>A:</b> |
1379 |
1381 Yes! The new build system has grown bit by bit as we converted |
1380 <hr /> |
1382 the old system. When all of the old build system is converted, |
1381 |
1383 we can take a step back and clean up the structure of the new build |
1382 <p>End of the OpenJDK build README document.</p> |
1384 system. Some of this we plan to do before replacing the old build |
1383 |
1385 system and some will need to wait until after. |
1384 <p>Please come again!</p> |
1386 </p> |
1385 </body> |
1387 |
|
1388 <p> |
|
1389 <b>Q:</b> |
|
1390 Is anything able to use the results of the new build's default make target? |
|
1391 <br> |
|
1392 <b>A:</b> |
|
1393 Yes, this is the minimal (or roughly minimal) |
|
1394 set of compiled output needed for a developer to actually |
|
1395 execute the newly built JDK. The idea is that in an incremental |
|
1396 development fashion, when doing a normal make, |
|
1397 you should only spend time recompiling what's changed |
|
1398 (making it purely incremental) and only do the work that's |
|
1399 needed to actually run and test your code. |
|
1400 The packaging stuff that is part of the <code>images</code> |
|
1401 target is not needed for a normal developer who wants to |
|
1402 test his new code. Even if it's quite fast, it's still unnecessary. |
|
1403 We're targeting sub-second incremental rebuilds! ;-) |
|
1404 (Or, well, at least single-digit seconds...) |
|
1405 </p> |
|
1406 |
|
1407 <p> |
|
1408 <b>Q:</b> |
|
1409 I usually set a specific environment variable when building, |
|
1410 but I can't find the equivalent in the new build. |
|
1411 What should I do? |
|
1412 <br> |
|
1413 <b>A:</b> |
|
1414 It might very well be that we have neglected to add support for |
|
1415 an option that was actually used from outside the build system. |
|
1416 Email us and we will add support for it! |
|
1417 </p> |
|
1418 |
|
1419 </blockquote> |
|
1420 |
|
1421 <h3><a name="performance">Build Performance Tips</a></h3> |
|
1422 <blockquote> |
|
1423 |
|
1424 <p>Building OpenJDK requires a lot of horsepower. |
|
1425 Some of the build tools can be adjusted to utilize more or less |
|
1426 of resources such as |
|
1427 parallel threads and memory. |
|
1428 The <code>configure</code> script analyzes your system and selects reasonable |
|
1429 values for such options based on your hardware. |
|
1430 If you encounter resource problems, such as out of memory conditions, |
|
1431 you can modify the detected values with:</p> |
|
1432 |
|
1433 <ul> |
|
1434 <li> |
|
1435 <b><code>--with-num-cores</code></b> |
|
1436 — |
|
1437 number of cores in the build system, |
|
1438 e.g. <code>--with-num-cores=8</code> |
|
1439 </li> |
|
1440 <li> |
|
1441 <b><code>--with-memory-size</code></b> |
|
1442 — memory (in MB) available in the build system, |
|
1443 e.g. <code>--with-memory-size=1024</code> |
|
1444 </li> |
|
1445 </ul> |
|
1446 |
|
1447 <p>It might also be necessary to specify the JVM arguments passed |
|
1448 to the Bootstrap JDK, using e.g. |
|
1449 <code>--with-boot-jdk-jvmargs="-Xmx8G -enableassertions"</code>. |
|
1450 Doing this will override the default JVM arguments |
|
1451 passed to the Bootstrap JDK.</p> |
|
1452 |
|
1453 |
|
1454 <p>One of the top goals of the new build system is to improve the |
|
1455 build performance and decrease the time needed to build. This will |
|
1456 soon also apply to the java compilation when the Smart Javac wrapper |
|
1457 is fully supported.</p> |
|
1458 |
|
1459 <p>At the end of a successful execution of <code>configure</code>, |
|
1460 you will get a performance summary, |
|
1461 indicating how well the build will perform. Here you will |
|
1462 also get performance hints. |
|
1463 If you want to build fast, pay attention to those!</p> |
|
1464 |
|
1465 <h4>Building with ccache</h4> |
|
1466 |
|
1467 <p>The OpenJDK build supports building with ccache |
|
1468 when using gcc or clang. Using ccache can |
|
1469 radically speed up compilation of native code if |
|
1470 you often rebuild the same sources. Your milage |
|
1471 may vary however so we recommend evaluating it for |
|
1472 yourself. To enable it, make sure it's on the path |
|
1473 and configure with <code>--enable-ccache</code>.</p> |
|
1474 |
|
1475 <h4>Building on local disk</h4> |
|
1476 |
|
1477 <p>If you are using network shares, e.g. via NFS, for your source code, |
|
1478 make sure the build directory is situated on local disk. |
|
1479 The performance |
|
1480 penalty is extremely high for building on a network share, |
|
1481 close to unusable.</p> |
|
1482 |
|
1483 <h4>Building only one JVM</h4> |
|
1484 |
|
1485 <p>The old build builds multiple JVMs on 32-bit systems (client and |
|
1486 server; and on Windows kernel as well). In the new build we have |
|
1487 changed this default to only build server when it's available. This |
|
1488 improves build times for those not interested in multiple JVMs. To |
|
1489 mimic the old behavior on platforms that support it, |
|
1490 use <code>--with-jvm-variants=client,server</code>.</p> |
|
1491 |
|
1492 <h4>Selecting the number of cores to build on</h4> |
|
1493 |
|
1494 <p>By default, <code>configure</code> will analyze your machine and run the make |
|
1495 process in parallel with as many threads as you have cores. This |
|
1496 behavior can be overridden, either "permanently" (on a <code>configure</code> |
|
1497 basis) using <code>--with-num-cores=N</code> or for a single build |
|
1498 only (on a make basis), using <code>make JOBS=N</code>.</p> |
|
1499 |
|
1500 <p>If you want to make a slower build just this time, to save some CPU |
|
1501 power for other processes, you can run |
|
1502 e.g. <code>make JOBS=2</code>. This will force the makefiles |
|
1503 to only run 2 parallel processes, or even <code>make JOBS=1</code> |
|
1504 which will disable parallelism.</p> |
|
1505 |
|
1506 <p>If you want to have it the other way round, namely having slow |
|
1507 builds default and override with fast if you're |
|
1508 impatient, you should call <code>configure</code> with |
|
1509 <code>--with-num-cores=2</code>, making 2 the default. |
|
1510 If you want to run with more |
|
1511 cores, run <code>make JOBS=8</code></p> |
|
1512 |
|
1513 </blockquote> |
|
1514 |
|
1515 <h3><a name="troubleshooting">Troubleshooting</a></h3> |
|
1516 <blockquote> |
|
1517 |
|
1518 <h4>Solving build problems</h4> |
|
1519 |
|
1520 <blockquote> |
|
1521 If the build fails (and it's not due to a compilation error in |
|
1522 a source file you've changed), the first thing you should do |
|
1523 is to re-run the build with more verbosity. |
|
1524 Do this by adding <code>LOG=debug</code> to your make command line. |
|
1525 <br> |
|
1526 The build log (with both stdout and stderr intermingled, |
|
1527 basically the same as you see on your console) can be found as |
|
1528 <code>build.log</code> in your build directory. |
|
1529 <br> |
|
1530 You can ask for help on build problems with the new build system |
|
1531 on either the |
|
1532 <a href="http://mail.openjdk.java.net/mailman/listinfo/build-dev"> |
|
1533 build-dev</a> |
|
1534 or the |
|
1535 <a href="http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev"> |
|
1536 build-infra-dev</a> |
|
1537 mailing lists. Please include the relevant parts |
|
1538 of the build log. |
|
1539 <br> |
|
1540 A build can fail for any number of reasons. |
|
1541 Most failures |
|
1542 are a result of trying to build in an environment in which all the |
|
1543 pre-build requirements have not been met. |
|
1544 The first step in |
|
1545 troubleshooting a build failure is to recheck that you have satisfied |
|
1546 all the pre-build requirements for your platform. |
|
1547 Scanning the <code>configure</code> log is a good first step, making |
|
1548 sure that what it found makes sense for your system. |
|
1549 Look for strange error messages or any difficulties that |
|
1550 <code>configure</code> had in finding things. |
|
1551 <br> |
|
1552 Some of the more common problems with builds are briefly |
|
1553 described |
|
1554 below, with suggestions for remedies. |
|
1555 <ul> |
|
1556 <li> |
|
1557 <b>Corrupted Bundles on Windows:</b> |
|
1558 <blockquote> |
|
1559 Some virus scanning software has been known to |
|
1560 corrupt the |
|
1561 downloading of zip bundles. |
|
1562 It may be necessary to disable the 'on access' or |
|
1563 'real time' |
|
1564 virus scanning features to prevent this corruption. |
|
1565 This type of "real time" virus scanning can also |
|
1566 slow down the |
|
1567 build process significantly. |
|
1568 Temporarily disabling the feature, or excluding the build |
|
1569 output directory may be necessary to get correct and |
|
1570 faster builds. |
|
1571 </blockquote> |
|
1572 </li> |
|
1573 <li> |
|
1574 <b>Slow Builds:</b> |
|
1575 <blockquote> |
|
1576 If your build machine seems to be overloaded from too many |
|
1577 simultaneous C++ compiles, try setting the |
|
1578 <code>JOBS=1</code> on the <code>make</code> command line. |
|
1579 Then try increasing the count slowly to an acceptable |
|
1580 level for your system. Also: |
|
1581 <blockquote> |
|
1582 Creating the javadocs can be very slow, |
|
1583 if you are running |
|
1584 javadoc, consider skipping that step. |
|
1585 <br> |
|
1586 Faster CPUs, more RAM, and a faster DISK usually helps. |
|
1587 The VM build tends to be CPU intensive |
|
1588 (many C++ compiles), |
|
1589 and the rest of the JDK will often be disk intensive. |
|
1590 <br> |
|
1591 Faster compiles are possible using a tool called |
|
1592 <a href="http://ccache.samba.org/" target="_blank">ccache</a>. |
|
1593 </blockquote> |
|
1594 </blockquote> |
|
1595 </li> |
|
1596 <li> |
|
1597 <b>File time issues:</b> |
|
1598 <blockquote> |
|
1599 If you see warnings that refer to file time stamps, e.g. |
|
1600 <blockquote> |
|
1601 <i>Warning message:</i><code> |
|
1602 File `xxx' has modification time in |
|
1603 the future.</code> |
|
1604 <br> |
|
1605 <i>Warning message:</i> <code> Clock skew detected. |
|
1606 Your build may |
|
1607 be incomplete.</code> |
|
1608 </blockquote> |
|
1609 These warnings can occur when the clock on the build |
|
1610 machine is out of |
|
1611 sync with the timestamps on the source files. |
|
1612 Other errors, apparently |
|
1613 unrelated but in fact caused by the clock skew, |
|
1614 can occur along with |
|
1615 the clock skew warnings. |
|
1616 These secondary errors may tend to obscure the |
|
1617 fact that the true root cause of the problem |
|
1618 is an out-of-sync clock. |
|
1619 <p> |
|
1620 If you see these warnings, reset the clock on the |
|
1621 build |
|
1622 machine, run "<code><i>gmake</i> clobber</code>" |
|
1623 or delete the directory |
|
1624 containing the build output, and restart the |
|
1625 build from the beginning. |
|
1626 </blockquote> |
|
1627 </li> |
|
1628 <li> |
|
1629 <b>Error message: |
|
1630 <code>Trouble writing out table to disk</code></b> |
|
1631 <blockquote> |
|
1632 Increase the amount of swap space on your build machine. |
|
1633 This could be caused by overloading the system and |
|
1634 it may be necessary to use: |
|
1635 <blockquote> |
|
1636 <code>make JOBS=1</code> |
|
1637 </blockquote> |
|
1638 to reduce the load on the system. |
|
1639 </blockquote> |
|
1640 </li> |
|
1641 <li> |
|
1642 <b>Error Message: |
|
1643 <code>libstdc++ not found:</code></b> |
|
1644 <blockquote> |
|
1645 This is caused by a missing libstdc++.a library. |
|
1646 This is installed as part of a specific package |
|
1647 (e.g. libstdc++.so.devel.386). |
|
1648 By default some 64-bit Linux versions (e.g. Fedora) |
|
1649 only install the 64-bit version of the libstdc++ package. |
|
1650 Various parts of the JDK build require a static |
|
1651 link of the C++ runtime libraries to allow for maximum |
|
1652 portability of the built images. |
|
1653 </blockquote> |
|
1654 </li> |
|
1655 <li> |
|
1656 <b>Linux Error Message: |
|
1657 <code>cannot restore segment prot after reloc</code></b> |
|
1658 <blockquote> |
|
1659 This is probably an issue with SELinux (See |
|
1660 <a href="http://en.wikipedia.org/wiki/SELinux" target="_blank"> |
|
1661 http://en.wikipedia.org/wiki/SELinux</a>). |
|
1662 Parts of the VM is built without the <code>-fPIC</code> for |
|
1663 performance reasons. |
|
1664 <p> |
|
1665 To completely disable SELinux: |
|
1666 <ol> |
|
1667 <li><code>$ su root</code></li> |
|
1668 <li><code># system-config-securitylevel</code></li> |
|
1669 <li><code>In the window that appears, select the SELinux tab</code></li> |
|
1670 <li><code>Disable SELinux</code></li> |
|
1671 </ol> |
|
1672 <p> |
|
1673 Alternatively, instead of completely disabling it you could |
|
1674 disable just this one check. |
|
1675 <ol> |
|
1676 <li>Select System->Administration->SELinux Management</li> |
|
1677 <li>In the SELinux Management Tool which appears, |
|
1678 select "Boolean" from the menu on the left</li> |
|
1679 <li>Expand the "Memory Protection" group</li> |
|
1680 <li>Check the first item, labeled |
|
1681 "Allow all unconfined executables to use |
|
1682 libraries requiring text relocation ..."</li> |
|
1683 </ol> |
|
1684 </blockquote> |
|
1685 </li> |
|
1686 <li> |
|
1687 <b>Windows Error Messages:</b> |
|
1688 <br> |
|
1689 <code>*** fatal error - couldn't allocate heap, ... </code> |
|
1690 <br> |
|
1691 <code>rm fails with "Directory not empty"</code> |
|
1692 <br> |
|
1693 <code>unzip fails with "cannot create ... Permission denied"</code> |
|
1694 <br> |
|
1695 <code>unzip fails with "cannot create ... Error 50"</code> |
|
1696 <br> |
|
1697 <blockquote> |
|
1698 The CYGWIN software can conflict with other non-CYGWIN |
|
1699 software. See the CYGWIN FAQ section on |
|
1700 <a href="http://cygwin.com/faq/faq.using.html#faq.using.bloda" target="_blank"> |
|
1701 BLODA (applications that interfere with CYGWIN)</a>. |
|
1702 </blockquote> |
|
1703 </li> |
|
1704 <li> |
|
1705 <b>Windows Error Message: <code>spawn failed</code></b> |
|
1706 <blockquote> |
|
1707 Try rebooting the system, or there could be some kind of |
|
1708 issue with the disk or disk partition being used. |
|
1709 Sometimes it comes with a "Permission Denied" message. |
|
1710 </blockquote> |
|
1711 </li> |
|
1712 </ul> |
|
1713 </blockquote> |
|
1714 |
|
1715 </blockquote> <!-- Troubleshooting --> |
|
1716 |
|
1717 </blockquote> <!-- Appendix A --> |
|
1718 |
|
1719 <!-- ====================================================== --> |
|
1720 <hr> |
|
1721 <h2><a name="gmake">Appendix B: GNU make</a></h2> |
|
1722 <blockquote> |
|
1723 |
|
1724 The Makefiles in the OpenJDK are only valid when used with the |
|
1725 GNU version of the utility command <code>make</code> |
|
1726 (usually called <code>gmake</code> on Solaris). |
|
1727 A few notes about using GNU make: |
|
1728 <ul> |
|
1729 <li> |
|
1730 You need GNU make version 3.81 or newer. On Windows 4.0 or |
|
1731 newer is recommended. |
|
1732 If the GNU make utility on your systems is not of a suitable |
|
1733 version see <a href="#buildgmake">"Building GNU make"</a>. |
|
1734 </li> |
|
1735 <li> |
|
1736 Place the location of the GNU make binary in the |
|
1737 <code>PATH</code>. |
|
1738 </li> |
|
1739 <li> |
|
1740 <strong>Solaris:</strong> |
|
1741 Do NOT use <code>/usr/bin/make</code> on Solaris. |
|
1742 If your Solaris system has the software |
|
1743 from the Solaris Developer Companion CD installed, |
|
1744 you should try and use <code>gmake</code> |
|
1745 which will be located in either the |
|
1746 <code>/usr/bin</code>, <code>/opt/sfw/bin</code> or |
|
1747 <code>/usr/sfw/bin</code> directory. |
|
1748 </li> |
|
1749 <li> |
|
1750 <strong>Windows:</strong> |
|
1751 Make sure you start your build inside a bash shell. |
|
1752 </li> |
|
1753 <li> |
|
1754 <strong>Mac OS X:</strong> |
|
1755 The XCode "command line tools" must be installed on your Mac. |
|
1756 </li> |
|
1757 </ul> |
|
1758 <p> |
|
1759 Information on GNU make, and access to ftp download sites, are |
|
1760 available on the |
|
1761 <a href="http://www.gnu.org/software/make/make.html" target="_blank"> |
|
1762 GNU make web site |
|
1763 </a>. |
|
1764 The latest source to GNU make is available at |
|
1765 <a href="http://ftp.gnu.org/pub/gnu/make/" target="_blank"> |
|
1766 ftp.gnu.org/pub/gnu/make/</a>. |
|
1767 </p> |
|
1768 |
|
1769 <h3><a name="buildgmake">Building GNU make</a></h3> |
|
1770 <blockquote> |
|
1771 First step is to get the GNU make 3.81 or newer source from |
|
1772 <a href="http://ftp.gnu.org/pub/gnu/make/" target="_blank"> |
|
1773 ftp.gnu.org/pub/gnu/make/</a>. |
|
1774 Building is a little different depending on the OS but is |
|
1775 basically done with: |
|
1776 <blockquote> |
|
1777 <code>bash ./configure</code> |
|
1778 <br> |
|
1779 <code>make</code> |
|
1780 </blockquote> |
|
1781 </blockquote> |
|
1782 |
|
1783 </blockquote> <!-- Appendix B --> |
|
1784 |
|
1785 <!-- ====================================================== --> |
|
1786 <hr> |
|
1787 <h2><a name="buildenvironments">Appendix C: Build Environments</a></h2> |
|
1788 <blockquote> |
|
1789 |
|
1790 <h3><a name="MBE">Minimum Build Environments</a></h3> |
|
1791 <blockquote> |
|
1792 This file often describes specific requirements for what we |
|
1793 call the |
|
1794 "minimum build environments" (MBE) for this |
|
1795 specific release of the JDK. |
|
1796 What is listed below is what the Oracle Release |
|
1797 Engineering Team will use to build the Oracle JDK product. |
|
1798 Building with the MBE will hopefully generate the most compatible |
|
1799 bits that install on, and run correctly on, the most variations |
|
1800 of the same base OS and hardware architecture. |
|
1801 In some cases, these represent what is often called the |
|
1802 least common denominator, but each Operating System has different |
|
1803 aspects to it. |
|
1804 <p> |
|
1805 In all cases, the Bootstrap JDK version minimum is critical, |
|
1806 we cannot guarantee builds will work with older Bootstrap JDK's. |
|
1807 Also in all cases, more RAM and more processors is better, |
|
1808 the minimums listed below are simply recommendations. |
|
1809 <p> |
|
1810 With Solaris and Mac OS X, the version listed below is the |
|
1811 oldest release we can guarantee builds and works, and the |
|
1812 specific version of the compilers used could be critical. |
|
1813 <p> |
|
1814 With Windows the critical aspect is the Visual Studio compiler |
|
1815 used, which due to it's runtime, generally dictates what Windows |
|
1816 systems can do the builds and where the resulting bits can |
|
1817 be used.<br> |
|
1818 <b>NOTE: We expect a change here off these older Windows OS releases |
|
1819 and to a 'less older' one, probably Windows 2008R2 X64.</b> |
|
1820 <p> |
|
1821 With Linux, it was just a matter of picking a |
|
1822 stable distribution that is a good representative for Linux |
|
1823 in general.<br> |
|
1824 <b>NOTE: We expect a change here from Fedora 9 to something else, |
|
1825 but it has not been completely determined yet, possibly |
|
1826 Ubuntu 12.04 X64, unbiased community feedback would be welcome on |
|
1827 what a good choice would be here.</b> |
|
1828 <p> |
|
1829 It is understood that most developers will NOT be using these |
|
1830 specific versions, and in fact creating these specific versions |
|
1831 may be difficult due to the age of some of this software. |
|
1832 It is expected that developers are more often using the more |
|
1833 recent releases and distributions of these operating systems. |
|
1834 <p> |
|
1835 Compilation problems with newer or different C/C++ compilers is a |
|
1836 common problem. |
|
1837 Similarly, compilation problems related to changes to the |
|
1838 <code>/usr/include</code> or system header files is also a |
|
1839 common problem with older, newer, or unreleased OS versions. |
|
1840 Please report these types of problems as bugs so that they |
|
1841 can be dealt with accordingly. |
|
1842 </p> |
|
1843 <table border="1"> |
|
1844 <thead> |
|
1845 <tr> |
|
1846 <th>Base OS and Architecture</th> |
|
1847 <th>OS</th> |
|
1848 <th>C/C++ Compiler</th> |
|
1849 <th>Bootstrap JDK</th> |
|
1850 <th>Processors</th> |
|
1851 <th>RAM Minimum</th> |
|
1852 <th>DISK Needs</th> |
|
1853 </tr> |
|
1854 </thead> |
|
1855 <tbody> |
|
1856 <tr> |
|
1857 <td>Linux X86 (32-bit) and X64 (64-bit)</td> |
|
1858 <td>Oracle Enterprise Linux 6.4</td> |
|
1859 <td>gcc 4.8.2 </td> |
|
1860 <td>JDK 8</td> |
|
1861 <td>2 or more</td> |
|
1862 <td>1 GB</td> |
|
1863 <td>6 GB</td> |
|
1864 </tr> |
|
1865 <tr> |
|
1866 <td>Solaris SPARCV9 (64-bit)</td> |
|
1867 <td>Solaris 10 Update 10</td> |
|
1868 <td>Studio 12 Update 3 + patches</td> |
|
1869 <td>JDK 8</td> |
|
1870 <td>4 or more</td> |
|
1871 <td>4 GB</td> |
|
1872 <td>8 GB</td> |
|
1873 </tr> |
|
1874 <tr> |
|
1875 <td>Solaris X64 (64-bit)</td> |
|
1876 <td>Solaris 10 Update 10</td> |
|
1877 <td>Studio 12 Update 3 + patches</td> |
|
1878 <td>JDK 8</td> |
|
1879 <td>4 or more</td> |
|
1880 <td>4 GB</td> |
|
1881 <td>8 GB</td> |
|
1882 </tr> |
|
1883 <tr> |
|
1884 <td>Windows X86 (32-bit)</td> |
|
1885 <td>Windows Server 2012 R2 x64</td> |
|
1886 <td>Microsoft Visual Studio C++ 2013 Professional Edition</td> |
|
1887 <td>JDK 8</td> |
|
1888 <td>2 or more</td> |
|
1889 <td>2 GB</td> |
|
1890 <td>6 GB</td> |
|
1891 </tr> |
|
1892 <tr> |
|
1893 <td>Windows X64 (64-bit)</td> |
|
1894 <td>Windows Server 2012 R2 x64</td> |
|
1895 <td>Microsoft Visual Studio C++ 2013 Professional Edition</td> |
|
1896 <td>JDK 8</td> |
|
1897 <td>2 or more</td> |
|
1898 <td>2 GB</td> |
|
1899 <td>6 GB</td> |
|
1900 </tr> |
|
1901 <tr> |
|
1902 <td>Mac OS X X64 (64-bit)</td> |
|
1903 <td>Mac OS X 10.9 "Mavericks"</td> |
|
1904 <td>XCode 5.1.1 or newer</td> |
|
1905 <td>JDK 8</td> |
|
1906 <td>2 or more</td> |
|
1907 <td>4 GB</td> |
|
1908 <td>6 GB</td> |
|
1909 </tr> |
|
1910 </tbody> |
|
1911 </table> |
|
1912 </blockquote> |
|
1913 |
|
1914 <!-- ====================================================== --> |
|
1915 <hr> |
|
1916 <h3><a name="SDBE">Specific Developer Build Environments</a></h3> |
|
1917 <blockquote> |
|
1918 We won't be listing all the possible environments, but |
|
1919 we will try to provide what information we have available to us. |
|
1920 <p> |
|
1921 <strong>NOTE: The community can help out by updating |
|
1922 this part of the document. |
|
1923 </strong> |
|
1924 |
|
1925 <h4><a name="fedora">Fedora</a></h4> |
|
1926 <blockquote> |
|
1927 After installing the latest |
|
1928 <a href="http://fedoraproject.org">Fedora</a> |
|
1929 you need to install several build dependencies. |
|
1930 The simplest way to do it is to execute the |
|
1931 following commands as user <code>root</code>: |
|
1932 <blockquote> |
|
1933 <code>yum-builddep java-1.7.0-openjdk</code> |
|
1934 <br> |
|
1935 <code>yum install gcc gcc-c++</code> |
|
1936 </blockquote> |
|
1937 <p> |
|
1938 In addition, it's necessary to set a few environment |
|
1939 variables for the build: |
|
1940 <blockquote> |
|
1941 <code>export LANG=C</code> |
|
1942 <br> |
|
1943 <code>export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}"</code> |
|
1944 </blockquote> |
|
1945 </blockquote> |
|
1946 |
|
1947 |
|
1948 <h4><a name="centos">CentOS 5.5</a></h4> |
|
1949 <blockquote> |
|
1950 After installing |
|
1951 <a href="http://www.centos.org/">CentOS 5.5</a> |
|
1952 you need to make sure you have |
|
1953 the following Development bundles installed: |
|
1954 <blockquote> |
|
1955 <ul> |
|
1956 <li>Development Libraries</li> |
|
1957 <li>Development Tools</li> |
|
1958 <li>Java Development</li> |
|
1959 <li>X Software Development (Including XFree86-devel)</li> |
|
1960 </ul> |
|
1961 </blockquote> |
|
1962 <p> |
|
1963 Plus the following packages: |
|
1964 <blockquote> |
|
1965 <ul> |
|
1966 <li>cups devel: Cups Development Package</li> |
|
1967 <li>alsa devel: Alsa Development Package</li> |
|
1968 <li>Xi devel: libXi.so Development Package</li> |
|
1969 </ul> |
|
1970 </blockquote> |
|
1971 <p> |
|
1972 The freetype 2.3 packages don't seem to be available, |
|
1973 but the freetype 2.3 sources can be downloaded, built, |
|
1974 and installed easily enough from |
|
1975 <a href="http://downloads.sourceforge.net/freetype"> |
|
1976 the freetype site</a>. |
|
1977 Build and install with something like: |
|
1978 <blockquote> |
|
1979 <code>bash ./configure</code> |
|
1980 <br> |
|
1981 <code>make</code> |
|
1982 <br> |
|
1983 <code>sudo -u root make install</code> |
|
1984 </blockquote> |
|
1985 <p> |
|
1986 Mercurial packages could not be found easily, but a Google |
|
1987 search should find ones, and they usually include Python if |
|
1988 it's needed. |
|
1989 </blockquote> |
|
1990 |
|
1991 <h4><a name="debian">Debian 5.0 (Lenny)</a></h4> |
|
1992 <blockquote> |
|
1993 After installing <a href="http://debian.org">Debian</a> 5 |
|
1994 you need to install several build dependencies. |
|
1995 The simplest way to install the build dependencies is to |
|
1996 execute the following commands as user <code>root</code>: |
|
1997 <blockquote> |
|
1998 <code>aptitude build-dep openjdk-7</code> |
|
1999 <br> |
|
2000 <code>aptitude install openjdk-7-jdk libmotif-dev</code> |
|
2001 </blockquote> |
|
2002 <p> |
|
2003 In addition, it's necessary to set a few environment |
|
2004 variables for the build: |
|
2005 <blockquote> |
|
2006 <code>export LANG=C</code> |
|
2007 <br> |
|
2008 <code>export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"</code> |
|
2009 </blockquote> |
|
2010 </blockquote> |
|
2011 |
|
2012 <h4><a name="ubuntu">Ubuntu 12.04</a></h4> |
|
2013 <blockquote> |
|
2014 After installing <a href="http://ubuntu.org">Ubuntu</a> 12.04 |
|
2015 you need to install several build dependencies. The simplest |
|
2016 way to do it is to execute the following commands: |
|
2017 <blockquote> |
|
2018 <code>sudo aptitude build-dep openjdk-7</code> |
|
2019 <br> |
|
2020 <code>sudo aptitude install openjdk-7-jdk</code> |
|
2021 </blockquote> |
|
2022 <p> |
|
2023 In addition, it's necessary to set a few environment |
|
2024 variables for the build: |
|
2025 <blockquote> |
|
2026 <code>export LANG=C</code> |
|
2027 <br> |
|
2028 <code>export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"</code> |
|
2029 </blockquote> |
|
2030 </blockquote> |
|
2031 |
|
2032 <h4><a name="opensuse">OpenSUSE 11.1</a></h4> |
|
2033 <blockquote> |
|
2034 After installing <a href="http://opensuse.org">OpenSUSE</a> 11.1 |
|
2035 you need to install several build dependencies. |
|
2036 The simplest way to install the build dependencies is to |
|
2037 execute the following commands: |
|
2038 <blockquote> |
|
2039 <code>sudo zypper source-install -d java-1_7_0-openjdk</code> |
|
2040 <br> |
|
2041 <code>sudo zypper install make</code> |
|
2042 </blockquote> |
|
2043 <p> |
|
2044 In addition, it is necessary to set a few environment |
|
2045 variables for the build: |
|
2046 <blockquote> |
|
2047 <code>export LANG=C</code> |
|
2048 <br> |
|
2049 <code>export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}"</code> |
|
2050 </blockquote> |
|
2051 <p> |
|
2052 Finally, you need to unset the <code>JAVA_HOME</code> |
|
2053 environment variable: |
|
2054 <blockquote> |
|
2055 <code>export -n JAVA_HOME</code> |
|
2056 </blockquote> |
|
2057 </blockquote> |
|
2058 |
|
2059 <h4><a name="mandriva">Mandriva Linux One 2009 Spring</a></h4> |
|
2060 <blockquote> |
|
2061 After installing <a href="http://mandriva.org">Mandriva</a> |
|
2062 Linux One 2009 Spring |
|
2063 you need to install several build dependencies. |
|
2064 The simplest way to install the build dependencies is to |
|
2065 execute the following commands as user <code>root</code>: |
|
2066 <blockquote> |
|
2067 <code>urpmi java-1.7.0-openjdk-devel make gcc gcc-c++ |
|
2068 freetype-devel zip unzip libcups2-devel libxrender1-devel |
|
2069 libalsa2-devel libstc++-static-devel libxtst6-devel |
|
2070 libxi-devel</code> |
|
2071 </blockquote> |
|
2072 <p> |
|
2073 In addition, it is necessary to set a few environment |
|
2074 variables for the build: |
|
2075 <blockquote> |
|
2076 <code>export LANG=C</code> |
|
2077 <br> |
|
2078 <code>export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}"</code> |
|
2079 </blockquote> |
|
2080 </blockquote> |
|
2081 |
|
2082 <h4><a name="opensolaris">OpenSolaris 2009.06</a></h4> |
|
2083 <blockquote> |
|
2084 After installing <a href="http://opensolaris.org">OpenSolaris</a> 2009.06 |
|
2085 you need to install several build dependencies. |
|
2086 The simplest way to install the build dependencies is to |
|
2087 execute the following commands: |
|
2088 <blockquote> |
|
2089 <code>pfexec pkg install SUNWgmake SUNWj7dev |
|
2090 sunstudioexpress SUNWcups SUNWzip SUNWunzip SUNWxwhl |
|
2091 SUNWxorg-headers SUNWaudh SUNWfreetype2</code> |
|
2092 </blockquote> |
|
2093 <p> |
|
2094 In addition, it is necessary to set a few environment |
|
2095 variables for the build: |
|
2096 <blockquote> |
|
2097 <code>export LANG=C</code> |
|
2098 <br> |
|
2099 <code>export PATH="/opt/SunStudioExpress/bin:${PATH}"</code> |
|
2100 </blockquote> |
|
2101 </blockquote> |
|
2102 |
|
2103 </blockquote> |
|
2104 |
|
2105 </blockquote> <!-- Appendix C --> |
|
2106 |
|
2107 <!-- ====================================================== --> |
|
2108 |
|
2109 <!-- Leave out Appendix D -- |
|
2110 |
|
2111 <hr> |
|
2112 <h2><a name="mapping">Appendix D: Mapping Old to New</a></h2> |
|
2113 <blockquote> |
|
2114 <p>This table will help you convert some idioms of the old build |
|
2115 system to the new build system.</p> |
|
2116 <table summary="Cheat sheet for converting from old to new build system"> |
|
2117 <tr valign="top"> |
|
2118 <th>In the old build system, you used to...</th> |
|
2119 <th>In the new build system, you should ...</th> |
|
2120 </tr> |
|
2121 <tr valign="top"> |
|
2122 <td>run <code>make sanity</code></td> |
|
2123 <td>run <code>bash ./configure</code></td> |
|
2124 </tr> |
|
2125 <tr valign="top"> |
|
2126 <td>set <code>ALT_OUTPUTDIR=build/my-special-output</code></td> |
|
2127 <td>before building the first time: |
|
2128 <br> |
|
2129 <code>cd build/my-special-output</code> |
|
2130 <br> |
|
2131 <code>bash ../../configure</code> |
|
2132 <br> |
|
2133 to build: |
|
2134 <br> |
|
2135 <code>cd build/my-special-output</code> |
|
2136 <br> |
|
2137 <code>make</code> |
|
2138 </td> |
|
2139 </tr> |
|
2140 <tr valign="top"> |
|
2141 <td>set <code>ALT_BOOTDIR=/opt/java/jdk7</code></td> |
|
2142 <td>run <code>configure --with-boot-jdk=/opt/java/jdk7</code></td> |
|
2143 </tr> |
|
2144 <tr valign="top"> |
|
2145 <td>run <code>make ARCH_DATA_MODEL=32</code></td> |
|
2146 <td>run <code>configure --with-target-bits=32</code></td> |
|
2147 </tr> |
|
2148 <tr valign="top"> |
|
2149 <td>set <code>BUILD_CLIENT_ONLY=true</code></td> |
|
2150 <td>run <code>configure --with-jvm-variants=client</code></td> |
|
2151 </tr> |
|
2152 <tr valign="top"> |
|
2153 <td>set <code>ALT_FREETYPE_LIB_PATH=/opt/freetype/lib</code> |
|
2154 and <code>ALT_FREETYPE_HEADERS_PATH=/opt/freetype/include</code></td> |
|
2155 <td>run <code>configure --with-freetype=/opt/freetype</code></td> |
|
2156 </tr> |
|
2157 <tr valign="top"> |
|
2158 <td>set <code>ALT_CUPS_HEADERS_PATH=/opt/cups/include</code></td> |
|
2159 <td>run <code>configure --with-cups=/opt/cups</code></td> |
|
2160 </tr> |
|
2161 <tr valign="top"> |
|
2162 <td>set <code>ALT_OPENWIN_HOME=/opt/X11R6</code></td> |
|
2163 <td>run <code>configure --with-x=/opt/X11R6</code></td> |
|
2164 </tr> |
|
2165 <tr valign="top"> |
|
2166 <td>set <code>ALT_MSVCRNN_DLL_PATH=c:/vc_redist</code></td> |
|
2167 <td>run <code>configure --with-msvcr100dll=/cygdrive/c/vc_redist</code></td> |
|
2168 </tr> |
|
2169 <tr valign="top"> |
|
2170 <td>set <code>ALT_COMPILER_PATH=/opt/my-gcc/bin/gcc</code></td> |
|
2171 <td>run <code>CC=/opt/my-gcc/bin/gcc configure</code> |
|
2172 or <code>CXX=/opt/my-gcc/bin/g++ configure</code> |
|
2173 </td> |
|
2174 </tr> |
|
2175 <tr valign="top"> |
|
2176 <td>set <code>BUILD_HEADLESS_ONLY=true</code></td> |
|
2177 <td>run <code>configure --disable-headful</code></td> |
|
2178 </tr> |
|
2179 <tr valign="top"> |
|
2180 <td>set <code>ALT_DEVTOOLS_PATH=/opt/mytools</code></td> |
|
2181 <td>just run <code>configure</code>, |
|
2182 your tools should be detected automatically. |
|
2183 If you have an unusual configuration, |
|
2184 add the tools directory to your <code>PATH</code>. |
|
2185 </td> |
|
2186 </tr> |
|
2187 <tr valign="top"> |
|
2188 <td>set <code>ALT_DROPS_DIR=/home/user/dropdir</code></td> |
|
2189 <td>source drops are not used anymore</td> |
|
2190 </tr> |
|
2191 <tr valign="top"> |
|
2192 <td>set <code>USE_ONLY_BOOTDIR_TOOLS=true</code></td> |
|
2193 <td>not needed, <code>configure</code> should always do the Right Thing automatically</td> |
|
2194 </tr> |
|
2195 <tr valign="top"> |
|
2196 <td>set <code>ALT_JDK_IMPORT_PATH=/opt/java/import-jdk</code> |
|
2197 or <code>ALT_BUILD_JDK_IMPORT_PATH=/opt/java/import-jdk</code> |
|
2198 </td> |
|
2199 <td>Importing JDKs is no longer possible, |
|
2200 but hotspot can be imported using |
|
2201 <code>--with-import-hotspot</code>. |
|
2202 Documentation on how to achieve a |
|
2203 similar solution will come soon! |
|
2204 </td> |
|
2205 </tr> |
|
2206 <tr valign="top"> |
|
2207 <td>set <code>EXTRA_CFLAGS=-Xfoo</code></td> |
|
2208 <td>run <code>CFLAGS=-Xfoo configure</code></td> |
|
2209 </tr> |
|
2210 <tr valign="top"> |
|
2211 <td>set <code>CROSS_COMPILE_ARCH=i586</code></td> |
|
2212 <td>see <a href="#sec7.3"> section 7.3, Cross-compilation</a></td> |
|
2213 </tr> |
|
2214 <tr valign="top"> |
|
2215 <td>set <code>SKIP_BOOT_CYCLE=false</code></td> |
|
2216 <td>Run <code>make bootcycle-images</code>.</td> |
|
2217 </tr> |
|
2218 </table> |
|
2219 |
|
2220 <h3><a name="variables">Environment/Make Variables</a></h3> |
|
2221 <p> |
|
2222 Some of the |
|
2223 environment or make variables (just called <b>variables</b> in this |
|
2224 document) that can impact the build are: |
|
2225 <blockquote> |
|
2226 <dl> |
|
2227 <dt><a name="path"><code>PATH</code></a> </dt> |
|
2228 <dd>Typically you want to set the <code>PATH</code> to include: |
|
2229 <ul> |
|
2230 <li>The location of the GNU make binary</li> |
|
2231 <li>The location of the Bootstrap JDK <code>java</code> |
|
2232 (see <a href="#bootjdk">Bootstrap JDK</a>)</li> |
|
2233 <li>The location of the C/C++ compilers |
|
2234 (see <a href="#compilers"><code>compilers</code></a>)</li> |
|
2235 <li>The location or locations for the Unix command utilities |
|
2236 (e.g. <code>/usr/bin</code>)</li> |
|
2237 </ul> |
|
2238 </dd> |
|
2239 <dt><code>MILESTONE</code> </dt> |
|
2240 <dd> |
|
2241 The milestone name for the build (<i>e.g.</i>"beta"). |
|
2242 The default value is "internal". |
|
2243 </dd> |
|
2244 <dt><code>BUILD_NUMBER</code> </dt> |
|
2245 <dd> |
|
2246 The build number for the build (<i>e.g.</i> "b27"). |
|
2247 The default value is "b00". |
|
2248 </dd> |
|
2249 <dt><a name="arch_data_model"><code>ARCH_DATA_MODEL</code></a></dt> |
|
2250 <dd>The <code>ARCH_DATA_MODEL</code> variable |
|
2251 is used to specify whether the build is to generate 32-bit or 64-bit |
|
2252 binaries. |
|
2253 The Solaris build supports either 32-bit or 64-bit builds, but |
|
2254 Windows and Linux will support only one, depending on the specific |
|
2255 OS being used. |
|
2256 Normally, setting this variable is only necessary on Solaris. |
|
2257 Set <code>ARCH_DATA_MODEL</code> to <code>32</code> for generating 32-bit binaries, |
|
2258 or to <code>64</code> for generating 64-bit binaries. |
|
2259 </dd> |
|
2260 <dt><a name="ALT_BOOTDIR"><code>ALT_BOOTDIR</code></a></dt> |
|
2261 <dd> |
|
2262 The location of the bootstrap JDK installation. |
|
2263 See <a href="#bootjdk">Bootstrap JDK</a> for more information. |
|
2264 You should always install your own local Bootstrap JDK and |
|
2265 always set <code>ALT_BOOTDIR</code> explicitly. |
|
2266 </dd> |
|
2267 <dt><a name="ALT_OUTPUTDIR"><code>ALT_OUTPUTDIR</code></a> </dt> |
|
2268 <dd> |
|
2269 An override for specifying the (absolute) path of where the |
|
2270 build output is to go. |
|
2271 The default output directory will be build/<i>platform</i>. |
|
2272 </dd> |
|
2273 <dt><a name="ALT_COMPILER_PATH"><code>ALT_COMPILER_PATH</code></a> </dt> |
|
2274 <dd> |
|
2275 The location of the C/C++ compiler. |
|
2276 The default varies depending on the platform. |
|
2277 </dd> |
|
2278 <dt><code><a name="ALT_CACERTS_FILE">ALT_CACERTS_FILE</a></code></dt> |
|
2279 <dd> |
|
2280 The location of the <a href="#cacerts">cacerts</a> file. |
|
2281 The default will refer to |
|
2282 <code>jdk/src/share/lib/security/cacerts</code>. |
|
2283 </dd> |
|
2284 <dt><a name="ALT_CUPS_HEADERS_PATH"><code>ALT_CUPS_HEADERS_PATH</code></a> </dt> |
|
2285 <dd> |
|
2286 The location of the CUPS header files. |
|
2287 See <a href="#cups">CUPS information</a> for more information. |
|
2288 If this path does not exist the fallback path is |
|
2289 <code>/usr/include</code>. |
|
2290 </dd> |
|
2291 <dt><a name="ALT_FREETYPE_LIB_PATH"><code>ALT_FREETYPE_LIB_PATH</code></a></dt> |
|
2292 <dd> |
|
2293 The location of the FreeType shared library. |
|
2294 See <a href="#freetype">FreeType information</a> for details. |
|
2295 </dd> |
|
2296 <dt><a name="ALT_FREETYPE_HEADERS_PATH"><code>ALT_FREETYPE_HEADERS_PATH</code></a></dt> |
|
2297 <dd> |
|
2298 The location of the FreeType header files. |
|
2299 See <a href="#freetype">FreeType information</a> for details. |
|
2300 </dd> |
|
2301 <dt><a name="ALT_JDK_DEVTOOLS_PATH"><code>ALT_JDK_DEVTOOLS_PATH</code></a></dt> |
|
2302 <dd> |
|
2303 The default root location of the devtools. |
|
2304 The default value is |
|
2305 <code>$(ALT_SLASH_JAVA)/devtools</code>. |
|
2306 </dd> |
|
2307 <dt><code><a name="ALT_DEVTOOLS_PATH">ALT_DEVTOOLS_PATH</a></code> </dt> |
|
2308 <dd> |
|
2309 The location of tools like the |
|
2310 <a href="#zip"><code>zip</code> and <code>unzip</code></a> |
|
2311 binaries, but might also contain the GNU make utility |
|
2312 (<code><i>gmake</i></code>). |
|
2313 So this area is a bit of a grab bag, especially on Windows. |
|
2314 The default value depends on the platform and |
|
2315 Unix Commands being used. |
|
2316 On Linux the default will be |
|
2317 <code>$(ALT_JDK_DEVTOOLS_PATH)/linux/bin</code>, |
|
2318 on Solaris |
|
2319 <code>$(ALT_JDK_DEVTOOLS_PATH)/<i>{sparc,i386}</i>/bin</code>, |
|
2320 and on Windows with CYGWIN |
|
2321 <code>/usr/bin</code>. |
|
2322 </dd> |
|
2323 <dt><a name="ALT_UNIXCCS_PATH"><code>ALT_UNIXCCS_PATH</code></a></dt> |
|
2324 <dd> |
|
2325 <strong>Solaris only:</strong> |
|
2326 An override for specifying where the Unix CCS |
|
2327 command set are located. |
|
2328 The default location is <code>/usr/ccs/bin</code> |
|
2329 </dd> |
|
2330 <dt><a name="ALT_SLASH_JAVA"><code>ALT_SLASH_JAVA</code></a></dt> |
|
2331 <dd> |
|
2332 The default root location for many of the ALT path locations |
|
2333 of the following ALT variables. |
|
2334 The default value is |
|
2335 <code>"/java"</code> on Solaris and Linux, |
|
2336 <code>"J:"</code> on Windows. |
|
2337 </dd> |
|
2338 |
|
2339 <dt><a name="ALT_OPENWIN_HOME"><code>ALT_OPENWIN_HOME</code></a></dt> |
|
2340 <dd> |
|
2341 The top-level directory of the libraries and include files |
|
2342 for the platform's |
|
2343 graphical programming environment. |
|
2344 The default location is platform specific. |
|
2345 For example, on Linux it defaults to <code>/usr/X11R6/</code>. |
|
2346 </dd> |
|
2347 <dt><strong>Windows specific:</strong></dt> |
|
2348 <dd> |
|
2349 <dl> |
|
2350 <dt><a name="ALT_WINDOWSSDKDIR"><code>ALT_WINDOWSSDKDIR</code></a> </dt> |
|
2351 <dd> |
|
2352 The location of the |
|
2353 Microsoft Windows SDK where some tools will be |
|
2354 located. |
|
2355 The default is whatever WINDOWSSDKDIR is set to |
|
2356 (or WindowsSdkDir) or the path |
|
2357 <br> |
|
2358 <code>c:\Program Files\Microsoft SDKs\Windows\v7.0a</code> |
|
2359 </dd> |
|
2360 <dt><code><a name="ALT_DXSDK_PATH">ALT_DXSDK_PATH</a></code> </dt> |
|
2361 <dd> |
|
2362 The location of the |
|
2363 <a href="#dxsdk">Microsoft DirectX 9 SDK</a>. |
|
2364 The default will be to try and use the DirectX environment |
|
2365 variable <code>DXSDK_DIR</code>, |
|
2366 failing that, look in <code>C:/DXSDK</code>. |
|
2367 </dd> |
|
2368 <dt><code><a name="ALT_MSVCRNN_DLL_PATH">ALT_MSVCRNN_DLL_PATH</a></code> </dt> |
|
2369 <dd> |
|
2370 The location of the |
|
2371 <a href="#msvcrNN"><code>MSVCR100.DLL</code></a>. |
|
2372 </dd> |
|
2373 </dl> |
|
2374 </dd> |
|
2375 <dt><strong>Cross-Compilation Support:</strong></dt> |
|
2376 <dd> |
|
2377 <dl> |
|
2378 <dt><a name="CROSS_COMPILE_ARCH"><code>CROSS_COMPILE_ARCH</code></a> </dt> |
|
2379 <dd> |
|
2380 Set to the target architecture of a |
|
2381 cross-compilation build. If set, this |
|
2382 variable is used to signify that we are |
|
2383 cross-compiling. The expectation |
|
2384 is that |
|
2385 <a href="#ALT_COMPILER_PATH"><code>ALT_COMPILER_PATH</code></a> |
|
2386 is set |
|
2387 to point to the cross-compiler and that any |
|
2388 cross-compilation specific flags |
|
2389 are passed using |
|
2390 <a href="#EXTRA_CFLAGS"><code>EXTRA_CFLAGS</code></a>. |
|
2391 The <a href="#ALT_OPENWIN_HOME"><code>ALT_OPENWIN_HOME</code></a> |
|
2392 variable should |
|
2393 also be set to point to the graphical header files |
|
2394 (e.g. X11) provided with |
|
2395 the cross-compiler. |
|
2396 When cross-compiling we skip execution of any demos |
|
2397 etc that may be built, and |
|
2398 also skip binary-file verification. |
|
2399 </dd> |
|
2400 <dt><code><a name="EXTRA_CFLAGS">EXTRA_CFLAGS</a></code> </dt> |
|
2401 <dd> |
|
2402 Used to pass cross-compilation options to the |
|
2403 cross-compiler. |
|
2404 These are added to the <code>CFLAGS</code> |
|
2405 and <code>CXXFLAGS</code> variables. |
|
2406 </dd> |
|
2407 <dt><code><a name="USE_ONLY_BOOTDIR_TOOLS">USE_ONLY_BOOTDIR_TOOLS</a></code> </dt> |
|
2408 <dd> |
|
2409 Used primarily for cross-compilation builds |
|
2410 (and always set in that case) |
|
2411 this variable indicates that tools from the |
|
2412 boot JDK should be used during |
|
2413 the build process, not the tools |
|
2414 (<code>javac</code>, <code>javah</code>, <code>jar</code>) |
|
2415 just built (which can't execute on the build host). |
|
2416 </dd> |
|
2417 <dt><code><a name="HOST_CC">HOST_CC</a></code> </dt> |
|
2418 <dd> |
|
2419 The location of the C compiler to generate programs |
|
2420 to run on the build host. |
|
2421 Some parts of the build generate programs that are |
|
2422 then compiled and executed |
|
2423 to produce other parts of the build. Normally the |
|
2424 primary C compiler is used |
|
2425 to do this, but when cross-compiling that would be |
|
2426 the cross-compiler and the |
|
2427 resulting program could not be executed. |
|
2428 On Linux this defaults to <code>/usr/bin/gcc</code>; |
|
2429 on other platforms it must be |
|
2430 set explicitly. |
|
2431 </dd> |
|
2432 </dl> |
|
2433 <dt><strong>Specialized Build Options:</strong></dt> |
|
2434 <dd> |
|
2435 Some build variables exist to support specialized build |
|
2436 environments and/or specialized |
|
2437 build products. Their use is only supported in those contexts: |
|
2438 <dl> |
|
2439 <dt><code><a name="BUILD_CLIENT_ONLY">BUILD_CLIENT_ONLY</a></code> </dt> |
|
2440 <dd> |
|
2441 Indicates this build will only contain the |
|
2442 Hotspot client VM. In addition to |
|
2443 controlling the Hotspot build target, |
|
2444 it ensures that we don't try to copy |
|
2445 any server VM files/directories, |
|
2446 and defines a default <code>jvm.cfg</code> file |
|
2447 suitable for a client-only environment. |
|
2448 Using this in a 64-bit build will |
|
2449 generate a sanity warning as 64-bit client |
|
2450 builds are not directly supported. |
|
2451 </dd> |
|
2452 <dt><code><a name="BUILD_HEADLESS_ONLY"></a>BUILD_HEADLESS_ONLY</code> </dt> |
|
2453 <dd> |
|
2454 Used when the build environment has no graphical |
|
2455 capabilities at all. This |
|
2456 excludes building anything that requires graphical |
|
2457 libraries to be available. |
|
2458 </dd> |
|
2459 <dt><code><a name="JAVASE_EMBEDDED"></a>JAVASE_EMBEDDED</code> </dt> |
|
2460 <dd> |
|
2461 Used to indicate this is a build of the Oracle |
|
2462 Java SE Embedded product. |
|
2463 This will enable the directives included in the |
|
2464 SE-Embedded specific build |
|
2465 files. |
|
2466 </dd> |
|
2467 <dt><code><a name="LIBZIP_CAN_USE_MMAP">LIBZIP_CAN_USE_MMAP</a></code> </dt> |
|
2468 <dd> |
|
2469 If set to false, disables the use of mmap by the |
|
2470 zip utility. Otherwise, |
|
2471 mmap will be used. |
|
2472 </dd> |
|
2473 <dt><code><a name="COMPRESS_JARS"></a>COMPRESS_JARS</code> </dt> |
|
2474 <dd> |
|
2475 If set to true, causes certain jar files that |
|
2476 would otherwise be built without |
|
2477 compression, to use compression. |
|
2478 </dd> |
|
2479 </dl> |
|
2480 </dd> |
|
2481 </dl> |
|
2482 </blockquote> |
|
2483 |
|
2484 </blockquote> <!-- Appendix D --> |
|
2485 |
|
2486 <!-- ====================================================== --> |
|
2487 <hr> |
|
2488 <p>End of OpenJDK README-builds.html document.<br>Please come again! |
|
2489 <hr> |
|
2490 |
|
2491 </body> |
|
2492 </html> |
1386 </html> |