diff --git a/.hgtags b/.hgtags index 78852de5bad73e6a8012e120bc48ff75210ae682..8d5bee022fb83584e67346423735ef3bdef0c9c4 100644 --- a/.hgtags +++ b/.hgtags @@ -109,3 +109,5 @@ cc58c11af15411042719e9c82707fdbef60a9e0f jdk7-b130 0f62a65fb666b337caa585015ab6ea2e60e709ca jdk7-b132 c6f380693342feadccc5fe2c5adf500e861361aa jdk7-b133 ddc2fcb3682ffd27f44354db666128827be7e3c3 jdk7-b134 +783bd02b4ab4596059c74b10a1793d7bd2f1c157 jdk7-b135 +2fe76e73adaa5133ac559f0b3c2c0707eca04580 jdk7-b136 diff --git a/README b/README index 722131d683f02b71c79b84c1444c399b5c0d00ec..db7346b443236a5a89a3b243dee814a2c3c32450 100644 --- a/README +++ b/README @@ -29,13 +29,14 @@ Simple Build Instructions: Set the environment variable ALT_BOOTDIR to the location of JDK 6. 2. Check the sanity of doing a build with your current system: - gnumake sanity + make sanity See README-builds.html if you run into problems. 3. Do a complete build of the OpenJDK: - gnumake all + make all The resulting JDK image should be found in build/*/j2sdk-image -where gnumake is GNU make 3.81 or newer, /usr/bin/make on Linux and -/usr/sfw/bin/gmake or /opt/sfw/bin/gmake on Solaris. +where make is GNU make 3.81 or newer, /usr/bin/make on Linux usually +is 3.81 or newer. +Complete details are available in README-builds.html. diff --git a/README-builds.html b/README-builds.html index b59457c74abea44c06c4e3b2d1e247503aa3fb2e..87b7cd80af29c5861495d39965e945b2db1910ec 100644 --- a/README-builds.html +++ b/README-builds.html @@ -54,7 +54,11 @@
- hg fclone http://openjdk.java.net/jdk7/jdk7 YourOpenJDK + hg fclone http://hg.openjdk.java.net/jdk7/jdk7 YourOpenJDKTo get the entire set of OpenJDK Mercurial repositories without using the Forest Extension:
- hg clone http://openjdk.java.net/jdk7/jdk7 YourOpenJDK + hg clone http://hg.openjdk.java.net/jdk7/jdk7 YourOpenJDK-
cd YourOpenJDK
sh ./get_source.sh @@ -207,66 +211,50 @@Linux X86 (32-bit) Fedora 9 -gcc 4 -JDK 6u14 FCS +gcc 4.3 +JDK 6u18 Linux X64 (64-bit) Fedora 9 -gcc 4 -JDK 6u14 FCS +gcc 4.3 +JDK 6u18 Solaris SPARC (32-bit) -Solaris 10u2 + patches - +
- See - SunSolve for patch downloads. -Solaris 10 Update 6 Sun Studio 12 Update 1 + patches -JDK 6u14 FCS +JDK 6u18 Solaris SPARCV9 (64-bit) -Solaris 10u2 + patches - +
- See - SunSolve for patch downloads. -Solaris 10 Update 6 Sun Studio 12 Update 1 + patches -JDK 6u14 FCS +JDK 6u18 Solaris X86 (32-bit) -Solaris 10u2 + patches - +
- See - SunSolve for patch downloads. -Solaris 10 Update 6 Sun Studio 12 Update 1 + patches -JDK 6u14 FCS +JDK 6u18 Solaris X64 (64-bit) -Solaris 10u2 + patches - +
- See - SunSolve for patch downloads. -Solaris 10 Update 6 Sun Studio 12 Update 1 + patches -JDK 6u14 FCS +JDK 6u18 Windows X86 (32-bit) Windows XP Microsoft Visual Studio C++ 2010 Professional Edition -JDK 6u14 FCS +JDK 6u18 @@ -300,7 +288,7 @@ way to do it is to execute the following commands as user root: - Windows X64 (64-bit) Windows Server 2003 - Enterprise x64 Edition Microsoft Visual Studio C++ 2010 Professional Edition -JDK 6u14 FCS +JDK 6u18 yum-builddep java-openjdk
+yum-builddep java-1.6.0-openjdk
yum install gcc gcc-c++
@@ -345,10 +333,10 @@
After installing - CentOS 5.2 + CentOS 5.5 you need to make sure you have the following Development bundles installed:@@ -356,7 +344,7 @@- Development Libraries
- Development Tools
- Java Development
-- X Software Development
+- X Software Development (Including XFree86-devel)
@@ -552,15 +540,105 @@ building the OpenJDK runtime libraries and misc files. The top level Makefile is used to build the entire OpenJDK. + +
++ The repositories jaxp and jaxws actually + do not contain the sources for JAXP or JAX-WS. + These products have their own open source procedures at their + JAXP and + JAX-WS home pages. + The OpenJDK project does need access to these sources to build + a complete JDK image because JAXP and JAX-WS are part of the JDK. + The current process for delivery of the JAXP and JAX-WS sources + involves so called "source drop bundles" downloaded from a public + website. + There are many reasons for this current mechanism, and it is + understood that this is not ideal for the open source community. + It is possible this process could change in the future. +
+ +
+ NOTE: The + Complete OpenJDK Source Bundles will contain the JAXP and + JAX-WS sources. +Creation of New Source Drop Bundles
+++ ++
+- + The JAXP or JAX-WS team prepares a new zip bundle, + places a copy in a public download area on java.net, + sends us a link and a list of CRs (Change Request Numbers). + The older download bundles should not be deleted. + It is the responsibility of the JAXP and JAX-WS team to + place the proper GPL legal notices on the sources + and do any filtering or java re-packaging for the + OpenJDK instances of these classes. +
+- + The OpenJDK team copies this new bundle into shared + area (e.g. /java/devtools/share/jdk7-drops). + Older bundles are never deleted so we retain the history. +
+- + The OpenJDK team edits the ant property file + jaxp/jaxp.properties or + jaxws/jaxws.properties to update the + base URL, the zip bundle name, and the MD5 checksum + of the zip bundle + (on Solaris: sum -c md5 bundlename) +
+- + OpenJDK team reviews and commits those changes with the + given CRs. +
+Using Source Drop Bundles
++++ The ant scripts that build jaxp and jaxws + will attempt to locate these zip bundles from the directory + in the environment variable + ALT_DROPS_DIR. + The checksums protect from getting the wrong, corrupted, or + improperly modified sources. + Once the sources are made available, the population will not + happen again unless a make clobber is requested + or the jaxp/drop/ or jaxws/drop/ + directory is explicitly deleted. +
+
+ NOTE: The default Makefile and ant script behavior + is to NOT download these bundles from the public http site. + In general, doing downloads + during the build process is not advised, it creates too much + unpredictability in the build process. + However, you can use make ALLOW_DOWNLOADS=true to + tell the ant script that the download of the zip bundle is + acceptable. ++ The recommended procedure for keeping a cache of these + source bundles would be to download them once, place them + in a directory outside the repositories, and then set + ALT_DROPS_DIR to refer + to that directory. + These drop bundles do change occasionally, so the newer + bundles may need to be added to this area from time to time. +
+
Building the OpenJDK - is done with a gmake - command line and various - environment or make variable settings that direct the make rules + is done with a GNU make command line + and various + environment or make variable settings that direct the makefile rules to where various components have been installed. Where possible the makefiles will attempt to located the various components in the default locations or any component specific @@ -578,7 +656,7 @@bash . jdk/make/jdk_generic_profile.sh - gmake sanity && gmake + make sanity && make
@@ -599,25 +677,31 @@ A few notes about using GNU make:
@@ -662,6 +741,34 @@ The latest source to GNU make is available at ftp.gnu.org/pub/gnu/make/. +
+ ++ First step is to get the GNU make 3.81 source from + + ftp.gnu.org/pub/gnu/make/. + Building is a little different depending on the OS and unix toolset + on Windows: ++
+- + Linux: + ./configure && make +
+- + Solaris: + ./configure && gmake CC=gcc +
+- + Windows for CYGWIN: + ./configure && make +
+- + Windows for MKS: (CYGWIN is recommended) + ./configure && make -f Makefile.win32 +
+
All OpenJDK builds require access to least Ant 1.7.1. The Ant tool is available from the - - Ant download site. + + Ant 1.7.1 archive download site. You should always make sure ant is in your PATH, and on Windows you may also need to set ANT_HOME to point to the location of the Ant installation, this is the directory pathname that contains a bin and lib. +
+ WARNING: Ant versions used from IDE tools like NetBeans + or installed via system packages may not operate the same + as the one obtained from the Ant download bundles. + These system and IDE installers sometimes choose to change + the ant installation enough to cause differences.
Linux gcc/binutils- The GNU gcc compiler version should be 4 or newer. + The GNU gcc compiler version should be 4.3 or newer. The compiler used should be the default compiler installed in /usr/bin.@@ -1047,21 +1160,16 @@ Windows i586: Microsoft Visual Studio 2010 CompilersWindows x64: Microsoft Visual Studio 2010 Professional Compiler- BEGIN WARNING: At this time (Spring/Summer 2010) JDK 7 is starting a transition to - use the newest VS2010 Microsoft compilers. These build instructions are updated - to show where we are going. We have a QA process to go through before - official builds actually use VS2010. So for now, official builds are - still using VS2003. No other compilers are known to build the entire JDK, + BEGIN WARNING: JDK 7 has transitioned to + use the newest VS2010 Microsoft compilers. + No other compilers are known to build the entire JDK, including non-open portions. - So for now you should be able to build with either VS2003 or VS2010. - We do not guarantee that VS2008 will work, although there is sufficient - makefile support to make at least basic JDK builds plausible. Visual Studio 2010 Express compilers are now able to build all the open source repositories, but this is 32 bit only. To build 64 bit - Windows binaries use the the 7.1 Windows SDK.END WARNING. + Windows binaries use the the 7.1 Windows SDK. + END WARNING.
- The 32-bit OpenJDK Windows build - requires + The 32-bit OpenJDK Windows build requires Microsoft Visual Studio C++ 2010 (VS2010) Professional Edition or Express compiler. The compiler and other tools are expected to reside @@ -1088,11 +1196,10 @@
- For X64, builds, when using the VS2010 Professional - compiler, the 64 bit build set up is much the same as 32 bit + For X64, the set up is much the same as 32 bit except that you run amd64\VCVARS64.BAT to set the compiler environment variables. - Previously 64 bit builds had used the 64 bit compiler in + Previously 64 bit builds had to use the 64 bit compiler in an unbundled Windows SDK but this is no longer necessary if you have VS2010 Professional.@@ -1614,6 +1721,13 @@ and on Windows with CYGWIN /usr/bin. +ALT_DROPS_DIR ++ The location of any source drop bundles + (see Managing the Source Drops). + The default will be + $(ALT_JDK_DEVTOOLS_PATH)/share/jdk7-drops. + ALT_UNIXCCS_PATH Solaris only: @@ -1649,6 +1763,12 @@ Where each of these directories contain the import JDK image for that platform. +ALT_OPENWIN_HOME ++ The top-level directory of the libraries and include files for the platform's + graphical programming environment. The default location is platform specific. + For example, on Linux it defaults to /usr/X11R6/. + Windows specific: @@ -1659,9 +1779,8 @@ located. The default is whatever WINDOWSSDKDIR is set to (or WindowsSdkDir) or the path -
- c:\Program Files\Microsoft SDKs\Windows\v6.1a -+
+ c:\Program Files\Microsoft SDKs\Windows\v7.0aALT_DXSDK_PATH @@ -1678,10 +1797,160 @@ +Cross-Compilation Support: ++ +
+- CROSS_COMPILE_ARCH
+- + Set to the target architecture of a cross-compilation build. If set, this + variable is used to signify that we are cross-compiling. The expectation + is that ALT_COMPILER_PATH is set + to point to the cross-compiler and that any cross-compilation specific flags + are passed using EXTRA_CFLAGS. + The ALT_OPENWIN_HOME variable should + also be set to point to the graphical header files (e.g. X11) provided with + the cross-compiler. + When cross-compiling we skip execution of any demos etc that may be built, and + also skip binary-file verification. +
+- EXTRA_CFLAGS
+- + Used to pass cross-compilation options to the cross-compiler. + These are added to the CFLAGS and CXXFLAGS variables. +
+- USE_ONLY_BOOTDIR_TOOLS
+- + Used primarily for cross-compilation builds (and always set in that case) + this variable indicates that tools from the boot JDK should be used during + the build process, not the tools (javac, javah, jar) + just built (which can't execute on the build host). +
+- HOST_CC
+- + The location of the C compiler to generate programs to run on the build host. + Some parts of the build generate programs that are then compiled and executed + to produce other parts of the build. Normally the primary C compiler is used + to do this, but when cross-compiling that would be the cross-compiler and the + resulting program could not be executed. + On Linux this defaults to /usr/bin/gcc; on other platforms it must be + set explicitly. +
+Specialized Build Options: ++ Some build variables exist to support specialized build environments and/or specialized + build products. Their use is only supported in those contexts: + +
+- BUILD_CLIENT_ONLY
+- + Indicates this build will only contain the Hotspot client VM. In addition to + controlling the Hotspot build target, it ensures that we don't try to copy + any server VM files/directories, and defines a default jvm.cfg file + suitable for a client-only environment. Using this in a 64-bit build will + generate a sanity warning as 64-bit client builds are not directly supported. +
+- BUILD_HEADLESS_ONLY
+- + Used when the build environment has no graphical capabilities at all. This + excludes building anything that requires graphical libraries to be available. +
+- JAVASE_EMBEDDED
+- + Used to indicate this is a build of the Oracle Java SE Embedded product. + This will enable the directives included in the SE-Embedded specific build + files. +
+- LIBZIP_CAN_USE_MMAP
+- + If set to false, disables the use of mmap by the zip utility. Otherwise, + mmap will be used. +
+- COMPRESS_JARS
+- + If set to true, causes certain jar files that would otherwise be built without + compression, to use compression. +
+
+ You don't have to use all these hints and tips, and in fact people do actually + build with systems that contradict these, but they might prove to be + helpful to some. ++ ++
+- + If make sanity does not work, find out why, fix that + before going any further. Or at least understand what the + complaints are from it. +
+- + JDK: Keep in mind that you are building a JDK, but you need + a JDK (BOOTDIR JDK) to build this JDK. +
+- + Ant: The ant utility is a java application and besides having + ant available to you, it's important that ant finds the right + java to run with. Make sure you can type ant -version + and get clean results with no error messages. +
+- + Linux: Try and favor the system packages over building your own + or getting packages from other areas. + Most Linux builds should be possible with the system's + available packages. +
+- + Solaris: Typically you will need to get compilers on your systems + and occasionally GNU make 3.81 if a gmake binary is not available. + The gmake binary might not be 3.81, be careful. +
+- + Windows VS2010: +
++
+- + Only the C++ part of VS2010 is needed. + Try to let the installation go to the default install directory. + Always reboot your system after installing VS2010. + The system environment variable VS100COMNTOOLS should be + set in your environment. +
+- + Make sure that TMP and TEMP are also set in the environment + and refer to Windows paths that exist, like C:\temp, + not /tmp, not /cygdrive/c/temp, and not C:/temp. + C:\temp is just an example, it is assumed that this area is + private to the user, so by default after installs you should + see a unique user path in these variables. +
+- + You need to use vsvars32.bat or vsvars64.bat to get the + PATH, INCLUDE, LIB, LIBPATH, and WINDOWSSDKDIR + variables set in your shell environment. + These bat files are not easy to use from a shell environment. + However, there is a script placed in the root jdk7 repository called + vsvars.sh that can help, it should only be done once in a shell + that will be doing the build, e.g.
+
+ sh ./make/scripts/vsvars.sh -v10 > settings
+ eval `cat settings`
+ Or just eval `sh ./make/scripts/vsvars.sh -v10`. +- + Windows: PATH order is critical, see the + paths section for more information. +
+- + Windows 64bit builds: Use ARCH_DATA_MODEL=64. +
+
A build can fail for any number of reasons. @@ -1706,6 +1975,19 @@ Some of the more common problems with builds are briefly described below, with suggestions for remedies.+
- + Corrupted Bundles on Windows: +
+ Some virus scanning software has been known to corrupt the + downloading of zip bundles. + It may be necessary to disable the 'on access' or 'real time' + virus scanning features to prevent this corruption. + This type of "real time" virus scanning can also slow down the + build process significantly. + Temporarily disabling the feature, or excluding the build + output directory may be necessary to get correct and faster builds. ++- Slow Builds:
@@ -1801,7 +2083,11 @@- - Windows Error Message: *** fatal error - couldn't allocate heap, ... + Windows Error Messages:
+ *** fatal error - couldn't allocate heap, ...
+ rm fails with "Directory not empty"
+ unzip fails with "cannot create ... Permission denied"
+ unzip fails with "cannot create ... Error 50"
The CYGWIN software can conflict with other non-CYGWIN software. See the CYGWIN FAQ section on @@ -1810,12 +2096,11 @@- - Windows Error Message: *** multiple target patterns. Stop. + Windows Error Message: spawn failed
- The CYGWIN make version 3.81 may not like the Windows C:/ - style paths, it may not like the ':' character in the path - when used in a makefile target definition. - See the gmake section. + Try rebooting the system, or there could be some kind of + issue with the disk or disk partition being used. + Sometimes it comes with a "Permission Denied" message.