├── README.md ├── dobuild └── doc ├── README.md ├── code-structure.md ├── jdk-dev-cycle.md ├── patch-structure.md ├── porting-process.md └── running-dobuild.md /README.md: -------------------------------------------------------------------------------- 1 | # Building OpenJDK on SunOS 2 | 3 | This is the (work in progress) SunOS jdk builder. 4 | 5 | The aim is to attempt to download, patch, and build any relevant jdk tag, 6 | and do so for SPARC and x86, and for illumos and Solaris 11.4. It has 7 | currently been tested on current illumos/x86 (specifically Tribblix 8 | m34), and Solaris 11 binary builds are available for 9 | [SPARC](https://pkgs.tribblix.org/openjdk/sparc-solaris/) 10 | up to jdk17, and 11 | [Intel](https://pkgs.tribblix.org/openjdk/intel-solaris/) 12 | up to jdk21. (Those are the latest LTS releases available; later development 13 | builds may also be available.) 14 | 15 | It is dependent on the 16 | [jdk-sunos-patches](https://github.com/ptribble/jdk-sunos-patches) 17 | repository, which holds all the patches for each tag. 18 | 19 | It should simply be a case of uttering 20 | 21 | ./dobuild jdk17u-jdk-17.0.8-ga 22 | 23 | Look in the "jdk-sunos-patches" repository for the list of known versions. 24 | 25 | Unless you're developing a new port, or bisecting a bug, generally the 26 | latest version of a given release (which will probably be one of the 27 | update releases, ie jdkXXu) ought to be a good place to start. For 28 | example: 29 | 30 | jdk11u-jdk-11.0.20-ga 31 | jdk12u-jdk-12.0.2+10 32 | jdk13u-jdk-13.0.14-ga 33 | jdk14u-jdk-14.0.2-12 34 | 35 | Are all supposed to be supported; later versions need the more extensive 36 | patches available as part of this project. 37 | 38 | ## Promoting a build 39 | 40 | Generally, you need to have a functioning build of one version of the jdk 41 | to build the next version. One point of this project is to allow you to build 42 | the whole chain from source. 43 | 44 | Some systems already have the required jdk versions available, in 45 | `/usr/jdk/instances`. Others do not. For those, you'll need to install 46 | a successful build in order to move on. So, the command 47 | 48 | ./dobuild -i jdk12u-jdk-12.0.2+10 49 | 50 | will make that version of jdk12 available, ready for the jdk13 build. 51 | 52 | To use a Liberica build (which would be a jdk11 release) give the absolute 53 | path to where it was unpacked, for example 54 | 55 | ./dobuild -i /path/to/jdk-11.0.18 56 | 57 | ## System Setup 58 | 59 | First decide on a directory tree where you're going to keep the code and 60 | run the builds. Then set the variables THOME and BUILDROOT in your 61 | environment to point to them, and create them. For example 62 | 63 | THOME=/var/tmp/java 64 | mkdir -p $THOME 65 | BUILDROOT=/var/tmp/java-build 66 | mkdir -p $BUILDROOT 67 | 68 | Then checkout the two repositories from github: 69 | 70 | cd $THOME 71 | git clone https://github.com/ptribble/jdk-sunos-builder 72 | git clone https://github.com/ptribble/jdk-sunos-patches 73 | 74 | You'll also need to install some software in order for the builds to work. 75 | 76 | ### Tribblix 77 | 78 | Install the following overlay: 79 | 80 | zap install-overlay openjdk-build 81 | 82 | ### Solaris 83 | 84 | I'm assuming you're using the Solaris 11 CBE, which already has most of the 85 | development toolchain preinstalled. But you will need: 86 | 87 | pkg install pkg:/developer/gcc-7 88 | pkg install pkg:/system/font/truetype/dejavu 89 | pkg install pkg:/developer/versioning/git 90 | pkg install pkg:/developer/build/autoconf 91 | 92 | And you'll need to download a Java 11 JDK to start from - use the 93 | [Liberica JDK](https://bell-sw.com/pages/downloads/#jdk-11-lts). 94 | 95 | ### Other illumos 96 | 97 | On other illumos distributions you'll need to ensure you have a complete 98 | developer toolchain and as many versions of java as are available in that 99 | distribution. 100 | 101 | ## Documentation 102 | 103 | More extensive [documentation](doc/README.md) is available, to help you 104 | through the general porting process. 105 | -------------------------------------------------------------------------------- /dobuild: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | # 3 | # SPDX-License-Identifier: CDDL-1.0 4 | # 5 | # {{{ CDDL HEADER 6 | # 7 | # This file and its contents are supplied under the terms of the 8 | # Common Development and Distribution License ("CDDL"), version 1.0. 9 | # You may only use this file in accordance with the terms of version 10 | # 1.0 of the CDDL. 11 | # 12 | # A full copy of the text of the CDDL should have accompanied this 13 | # source. A copy of the CDDL is also available via the Internet at 14 | # http://www.illumos.org/license/CDDL. 15 | # 16 | # }}} 17 | # 18 | # Copyright 2025 Peter Tribble 19 | # 20 | 21 | # 22 | # this is the SunOS jdk builder 23 | # 24 | # it will attempt to download, patch, and build any jdk tag, and do so for 25 | # SPARC and x86, and for illumos and Solaris 11.4 26 | # 27 | # will also function on SPARC/Linux (specifically debian-sparc) to 28 | # validate the SPARC port on a regularly supported OS, although this 29 | # script need to be called explicitly via bash, as the default sh of 30 | # dash won't work 31 | # 32 | # it is dependent on the "jdk-sunos-patches" repository, which holds 33 | # all the patches for each tag 34 | # 35 | 36 | # 37 | # this is where the repositories are rooted 38 | # 39 | THOME=${THOME:-/packages/localsrc/Tribblix} 40 | 41 | # 42 | # this is where the work area is rooted 43 | # note that if you have a separate pool, /var/tmp is probably a bad idea 44 | # 45 | BUILDROOT=${BUILDROOT:-/packages/localsrc/tmp} 46 | 47 | # 48 | # the is where the patches live 49 | # 50 | JPATCHDIR=${THOME}/jdk-sunos-patches 51 | 52 | # 53 | # this is where jdk tarballs are cached 54 | # the 2nd is an oddity for my personal build host 55 | # 56 | JCACHEDIR=${THOME}/tarballs 57 | JCACHEDIR2=${THOME}/large-tarballs 58 | 59 | # 60 | # this is where the build takes place 61 | # 62 | JBUILD=${BUILDROOT}/ud 63 | 64 | # 65 | # this is where it will look for bootstrap copies of the jdk 66 | # (in addition to /usr/jdk/instances) 67 | # 68 | JINSTANCES=${BUILDROOT}/jdk/instances 69 | 70 | # 71 | # this is where exported tarballs will be placed 72 | # 73 | JEXPORTDIR=${BUILDROOT}/exports 74 | 75 | # 76 | # this is where extra components needed for testing will be placed 77 | # 78 | TESTROOT=${BUILDROOT}/test 79 | 80 | # 81 | # need gtar gpatch sed/gsed 82 | # 83 | TAR="/usr/bin/gtar" 84 | GPATCH="/usr/bin/gpatch" 85 | SED="/usr/bin/sed" 86 | 87 | # 88 | # if you want to enable a different toolchain, then this will be set 89 | # this will also apply an extra toolchain patch, using the fixed name 90 | # toolchain-foo.patch 91 | # and rewrite the build script 92 | # 93 | JTOOLCHAIN="" 94 | 95 | # 96 | # Usage: dobuild [flags] tag 97 | # 98 | # valid flags are: 99 | # -b [build] 100 | # -B [build, remove existing copy first] 101 | # -c cpu [override cpu (sparc or x86)] 102 | # -C flags [extra flags to pass to configure] 103 | # -d [download] 104 | # -e [export] 105 | # -f feature [enable given patch feature] 106 | # -i [install] 107 | # -k toolchain [optionally build with solstudio or clang] 108 | # -o os [override os (illumos or Solaris)] 109 | # -p [patch] 110 | # -P [patch, remove existing copy first] 111 | # -t [enable tests] 112 | # -T type [build type - release, fastdebug, slowdebug, optimized] 113 | # -z [build the zero variant] 114 | # 115 | # previous steps will be executed if necessary, but the expected workflow 116 | # is to first download, then repeat the patch step until clean, then run 117 | # the build step until that's clean 118 | # 119 | DODOWNLOAD="" 120 | DOPATCH="" 121 | DOBUILD="" 122 | DOINSTALL="" 123 | DOCLEAN="" 124 | JFEATURE="" 125 | JEXTRACONF="" 126 | JTYPECONF="" 127 | JBUILDTYPE="" 128 | JZERO="" 129 | 130 | # 131 | # variables 132 | # 133 | # JARCH - sparc or i386 134 | # JOS - Solaris or illumos or GNU/Linux 135 | # 136 | # there are additional patches applied dependent on these 137 | # 138 | JARCH=$(uname -p) 139 | case $(uname -o) in 140 | illumos) 141 | JOS="illumos" 142 | ;; 143 | Solaris) 144 | JOS="solaris" 145 | SED="/usr/gnu/bin/sed" 146 | ;; 147 | GNU/Linux) 148 | JOS="linux" 149 | TAR="/usr/bin/tar" 150 | SED="/usr/bin/sed" 151 | GPATCH="/usr/bin/patch" 152 | JARCH=$(uname -m) 153 | case $JARCH in 154 | sparc64) 155 | JARCH="sparc" 156 | ;; 157 | *) 158 | echo "Linux only supported on sparc64" 159 | exit 1 160 | ;; 161 | esac 162 | ;; 163 | *) 164 | echo "Unknown OS, unable to continue" 165 | exit 1 166 | ;; 167 | esac 168 | 169 | dohelp() { 170 | cat <> .jdk_sunos_variant 702 | fi 703 | if [ -n "${JTOOLCHAIN}" ]; then 704 | if [ ! -f .jdk_sunos_variant ]; then 705 | touch .jdk_sunos_variant 706 | fi 707 | echo "${JTOOLCHAIN}" >> .jdk_sunos_variant 708 | fi 709 | if [ -n "${JBUILDTYPE}" ]; then 710 | if [ ! -f .jdk_sunos_variant ]; then 711 | touch .jdk_sunos_variant 712 | fi 713 | echo "${JBUILDTYPE}" >> .jdk_sunos_variant 714 | fi 715 | } 716 | 717 | # 718 | # install a copy of the jdk into the alternate area 719 | # 720 | # the argument can be either a tag, like a normal build, or 721 | # an absolute path, presumably to a bootstrap kit you've 722 | # unpacked somewhere else 723 | # 724 | do_install() { 725 | JDKVER=$1 726 | case $JDKVER in 727 | /*) 728 | if [ ! -x "${JDKVER}/bin/java" ]; then 729 | bail "unable to find java in ${JDKVER}" 730 | fi 731 | # now we need to work out what version it is 732 | # there's no easy way to do this 733 | # my builds might appear as openjdkXX or jdkXX 734 | # Liberica is eg jdk-11.0.18 735 | NVER=$(basename "${JDKVER}") 736 | case $NVER in 737 | jdk11*|openjdk11*|jdk-11*|openjdk-11*) 738 | mver=jdk11 739 | ;; 740 | jdk12*|openjdk12*|jdk-12*|openjdk-12*) 741 | mver=jdk12 742 | ;; 743 | jdk13*|openjdk13*|jdk-13*|openjdk-13*) 744 | mver=jdk13 745 | ;; 746 | jdk14*|openjdk14*|jdk-14*|openjdk-14*) 747 | mver=jdk14 748 | ;; 749 | jdk15*|openjdk15*|jdk-15*|openjdk-15*) 750 | mver=jdk15 751 | ;; 752 | jdk16*|openjdk16*|jdk-16*|openjdk-16*) 753 | mver=jdk16 754 | ;; 755 | jdk17*|openjdk17*|jdk-17*|openjdk-17*) 756 | mver=jdk17 757 | ;; 758 | jdk18*|openjdk18*|jdk-18*|openjdk-18*) 759 | mver=jdk18 760 | ;; 761 | jdk19*|openjdk19*|jdk-19*|openjdk-19*) 762 | mver=jdk19 763 | ;; 764 | jdk20*|openjdk20*|jdk-20*|openjdk-20*) 765 | mver=jdk20 766 | ;; 767 | jdk21*|openjdk21*|jdk-21*|openjdk-21*) 768 | mver=jdk21 769 | ;; 770 | jdk22*|openjdk22*|jdk-22*|openjdk-22*) 771 | mver=jdk22 772 | ;; 773 | jdk23*|openjdk23*|jdk-23*|openjdk-23*) 774 | mver=jdk23 775 | ;; 776 | *) 777 | bail "unrecognised version" 778 | ;; 779 | esac 780 | # looks like a successful build 781 | rm -f "${JINSTANCES}/${mver}" 782 | if [ ! -d "${JINSTANCES}" ]; then 783 | mkdir -p "${JINSTANCES}" 784 | fi 785 | if [ ! -d "${JINSTANCES}" ]; then 786 | bail "unable to create $JINSTANCES" 787 | fi 788 | ln -s "${JDKVER}" "${JINSTANCES}/${mver}" 789 | echo "Successfully installed:" 790 | ${JINSTANCES}/${mver}/bin/java -version 791 | ;; 792 | *) 793 | mver=$(major_java_version "$JDKVER") 794 | if [ ! -d "${JBUILD}/${JDKVER}" ]; then 795 | bail "no built tag $JDKVER" 796 | fi 797 | NJDIR=$(echo ${JBUILD}/${JDKVER}/build/*/images/jdk) 798 | if [ ! -d "${NJDIR}" ]; then 799 | bail "unable to find build area" 800 | fi 801 | if [ ! -x "${NJDIR}/bin/java" ]; then 802 | bail "unable to find java in build area" 803 | fi 804 | # looks like a successful build 805 | rm -f "${JINSTANCES}/${mver}" 806 | if [ ! -d "${JINSTANCES}" ]; then 807 | mkdir -p "${JINSTANCES}" 808 | fi 809 | if [ ! -d "${JINSTANCES}" ]; then 810 | bail "unable to create $JINSTANCES" 811 | fi 812 | ln -s "${NJDIR}" "${JINSTANCES}/${mver}" 813 | echo "Successfully installed:" 814 | ${JINSTANCES}/${mver}/bin/java -version 815 | ;; 816 | esac 817 | } 818 | 819 | # 820 | # create a versioned tarball of a jdk image 821 | # if there's variant information, use that to tag the name 822 | # 823 | do_export() { 824 | JDKVER=$1 825 | JDKTARNAME="${JDKVER}" 826 | if [ ! -d "${JEXPORTDIR}" ]; then 827 | mkdir -p "${JEXPORTDIR}" 828 | fi 829 | if [ ! -d "${JEXPORTDIR}" ]; then 830 | bail "Unable to create ${JEXPORTDIR} to store images" 831 | fi 832 | mver=$(major_java_version "$JDKVER") 833 | if [ ! -d "${JBUILD}/${JDKVER}" ]; then 834 | bail "no built tag $JDKVER" 835 | fi 836 | NJDIR=$(echo ${JBUILD}/${JDKVER}/build/*/images/jdk) 837 | if [ ! -d "${NJDIR}" ]; then 838 | bail "unable to find build area" 839 | fi 840 | if [ ! -x "${NJDIR}/bin/java" ]; then 841 | bail "unable to find java in build area" 842 | fi 843 | # 844 | # we've found it, look for variant information 845 | # 846 | if [ -f "${JBUILD}/${JDKVER}/.jdk_sunos_variant" ]; then 847 | cat "${JBUILD}/${JDKVER}/.jdk_sunos_variant" | while read vdata 848 | do 849 | JDKTARNAME="${JDKTARNAME}-${vdata}" 850 | done 851 | fi 852 | # looks like a successful build 853 | # the image we start from is unversioned, and we want a versioned 854 | # tarball that unpacks into a versioned directory 855 | # so create a staging area 856 | TDIR=/tmp/jdk-exporter.$$ 857 | rm -fr "$TDIR" 858 | mkdir "$TDIR" 859 | if [ ! -d "${TDIR}" ]; then 860 | bail "unable to create staging area" 861 | fi 862 | # now we can copy things across 863 | echo "Creating tarball" 864 | cd ${JBUILD}/${JDKVER}/build/*/images 865 | tar cf - jdk | ( cd "$TDIR" ; tar xf -) 866 | cd "$TDIR" 867 | mv jdk "$JDKTARNAME" 868 | tar cf - "$JDKTARNAME" | gzip > "${JEXPORTDIR}/${JDKTARNAME}.tar.gz" 869 | ls -l "${JEXPORTDIR}/${JDKTARNAME}.tar.gz" 870 | } 871 | 872 | # 873 | # catch the install early 874 | # 875 | if [ -n "${DOINSTALL}" ]; then 876 | do_install "$JDKVER" 877 | exit 0 878 | fi 879 | 880 | # 881 | # catch the export early 882 | # 883 | if [ -n "${DOEXPORT}" ]; then 884 | do_export "$JDKVER" 885 | exit 0 886 | fi 887 | 888 | # 889 | # sanity check/debug 890 | # 891 | if [ ! -d "${JCACHEDIR}" ]; then 892 | mkdir -p "$JCACHEDIR" 893 | if [ ! -d "${JCACHEDIR}" ]; then 894 | bail "Unable to create ${JCACHEDIR} to store tarballs" 895 | fi 896 | fi 897 | if [ ! -d "${JPATCHDIR}" ]; then 898 | bail "No patch directory, have you checked out jdk-sunos-patches?" 899 | fi 900 | if [ -n "${JBUILDTYPE}" ]; then 901 | case ${JBUILDTYPE} in 902 | release|fastdebug|slowdebug|optimized) 903 | JTYPECONF="--with-debug-level=${JBUILDTYPE}" 904 | ;; 905 | *) 906 | bail "Invalid debug level for -T" 907 | ;; 908 | esac 909 | fi 910 | 911 | # 912 | # if testing, we need to make sure the test components are downloaded 913 | # and installed, so do that now (it needs JCACHEDIR) 914 | # 915 | if [ -n "${DOTEST}" ]; then 916 | initialize_test 917 | fi 918 | 919 | # 920 | # there are 2 versions we use 921 | # JDKVER is the version we want to build 922 | # JDKALIAS is the version of the patches/scripts we use 923 | # 924 | JDKALIAS=${JDKVER} 925 | 926 | mver=$(major_java_version "$JDKVER") 927 | if [ -f "${JPATCHDIR}/${mver}/${JDKVER}.alias" ]; then 928 | JDKALIAS=$(<${JPATCHDIR}/${mver}/${JDKVER}.alias) 929 | echo "Found alias $JDKALIAS for $JDKVER" 930 | fi 931 | tball=$(find_tarball "$JDKVER") 932 | if [ -s "${tball}" ]; then 933 | echo "Found existing download ${tball}" 934 | fi 935 | if [ -f "${JPATCHDIR}/${mver}/${JDKALIAS}.pls" ]; then 936 | echo "Found patch list for $JDKVER" 937 | else 938 | bail "No patch list for $JDKVER" 939 | fi 940 | if [ -d "${JPATCHDIR}/${mver}/${JDKALIAS}" ]; then 941 | echo "Found patch directory for $JDKVER" 942 | else 943 | bail "No patch directory for $JDKVER" 944 | fi 945 | if [ -f "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" ]; then 946 | echo "Found build script for $JDKVER" 947 | else 948 | bail "No build script for $JDKVER" 949 | fi 950 | 951 | # 952 | # if asked for an alternate toolchain, check that there is a patch to support 953 | # that toolchain 954 | # 955 | if [ -n "${JTOOLCHAIN}" ]; then 956 | if [ -f "${JPATCHDIR}/${mver}/${JDKALIAS}/toolchain-${JTOOLCHAIN}.patch" ]; then 957 | echo "Found toolchain patch to support ${JTOOLCHAIN}" 958 | else 959 | bail "No toolchain patch for ${JTOOLCHAIN}" 960 | fi 961 | fi 962 | 963 | # 964 | # from here on we do some work 965 | # 966 | 967 | # 968 | # phase 1 is to download, if necessary 969 | # stop if that's all we were asked to do 970 | # 971 | if [ -n "${DODOWNLOAD}" ]; then 972 | echo "Downloading only" 973 | fi 974 | if [ -s "${tball}" ]; then 975 | echo "Already downloaded $tball" 976 | else 977 | do_download "$JDKVER" 978 | tball=$(find_tarball "$JDKVER") 979 | fi 980 | if [ ! -s "${tball}" ]; then 981 | bail "no download found" 982 | fi 983 | if [ -n "${DODOWNLOAD}" ]; then 984 | exit 0 985 | fi 986 | 987 | # 988 | # phase 2 is to unpack and apply the patches, if necessary 989 | # we already ensured the tarball was downloaded above 990 | # stop if that's all we were asked to do 991 | # 992 | if [ -n "${DOPATCH}" ]; then 993 | echo "Patching only" 994 | fi 995 | # 996 | # with -P and -B we clean up an existing copy 997 | # 998 | if [ -n "${DOCLEAN}" ]; then 999 | if [ -d "${JBUILD}/${JDKVER}" ]; then 1000 | echo "Removing existing unpacked ${JDKVER}" 1001 | rm -fr "${JBUILD}/${JDKVER}" 1002 | fi 1003 | fi 1004 | if [ -d "${JBUILD}/${JDKVER}" ]; then 1005 | echo "Found existing unpacked ${JDKVER}" 1006 | else 1007 | if [ ! -d "${JBUILD}" ]; then 1008 | mkdir -p "${JBUILD}" 1009 | fi 1010 | if [ ! -d "${JBUILD}" ]; then 1011 | bail "cannot create build area $JBUILD" 1012 | fi 1013 | cd "$JBUILD" || bail "cannot cd to build area $JBUILD" 1014 | do_unpack "$JDKVER" "$tball" 1015 | fi 1016 | if [ ! -d "${JBUILD}/${JDKVER}" ]; then 1017 | bail "Unpack of $JDKVER failed" 1018 | fi 1019 | if [ -n "${DOPATCH}" ]; then 1020 | exit 0 1021 | fi 1022 | 1023 | # 1024 | # phase 3 is to run a build 1025 | # we know the location exists from above 1026 | # 1027 | cd "${JBUILD}/${JDKVER}" || bail "cannot cd to build directory $JBUILD/$JDKVER" 1028 | NJDIR=$(echo build/*/images/jdk) 1029 | if [ -x "${NJDIR}/bin/java" ]; then 1030 | echo "Build already ran successfully" 1031 | else 1032 | if [ -n "${DOTEST}" ]; then 1033 | # 1034 | # there are 2 ways for configure to pick up jtreg, the simplest 1035 | # is to set JT_HOME 1036 | # 1037 | JT_HOME="${TESTROOT}/jtreg" 1038 | export JT_HOME 1039 | # 1040 | # but gtest involves rewriting the configure command 1041 | # 1042 | enable_gtest "${mver}" "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" 1043 | # 1044 | # put in a little marker to say we've actually done this 1045 | # 1046 | touch .jdk_sunos_test_enabled 1047 | fi 1048 | if [ -n "${JEXTRACONF}" ]; then 1049 | enable_configure_flags "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" "${JEXTRACONF}" 1050 | fi 1051 | if [ -n "${JTYPECONF}" ]; then 1052 | enable_configure_flags "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" "${JTYPECONF}" 1053 | fi 1054 | if [ -n "${JZERO}" ]; then 1055 | enable_configure_flags "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" "--enable-jvm-feature-zero --with-jvm-variants=zero" 1056 | fi 1057 | find_boot_jdk "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" 1058 | fixup_build_script "${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" 1059 | save_build_metadata 1060 | echo "Running ${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh" 1061 | ${JPATCHDIR}/${mver}/${JDKALIAS}/build.sh 1062 | # 1063 | # if we rewrote the build script, restore it 1064 | # old Solaris git doesn't understand restore, do it the old way 1065 | # 1066 | cd "${JPATCHDIR}" || bail "unable to cd back to patch repo" 1067 | git checkout -- "${mver}/${JDKALIAS}/build.sh" 1068 | fi 1069 | 1070 | # 1071 | # was the build successful? 1072 | # 1073 | cd "${JBUILD}/${JDKVER}" || bail "cannot cd to build directory $JBUILD/$JDKVER" 1074 | NJDIR=$(echo build/*/images/jdk) 1075 | if [ -x "${NJDIR}/bin/java" ]; then 1076 | echo "Build of ${JDKVER} completed successfully" 1077 | else 1078 | bail "Build of ${JDKVER} failed" 1079 | fi 1080 | 1081 | # 1082 | # if we were asked to just do a build, stop here 1083 | # 1084 | if [ -n "${DOBUILD}" ]; then 1085 | exit 0 1086 | fi 1087 | 1088 | # 1089 | # if testing isn't requested, also stop 1090 | # 1091 | if [ -z "${DOTEST}" ]; then 1092 | exit 0 1093 | fi 1094 | 1095 | # 1096 | # run the tests 1097 | # 1098 | cd "${JBUILD}/${JDKVER}" || bail "cannot cd to build directory $JBUILD/$JDKVER" 1099 | # 1100 | # the tests need to be configured at build time, first check 1101 | # if they were 1102 | # 1103 | if [ ! -f .jdk_sunos_test_enabled ]; then 1104 | bail "build was not configured for testing" 1105 | fi 1106 | # 1107 | # these are the base tests, we need a way to extend them later 1108 | # 1109 | env PATH=/usr/bin:/usr/sbin:/usr/sfw/bin:/usr/gnu/bin gmake test TEST="gtest:all" 1110 | env PATH=/usr/bin:/usr/sbin:/usr/sfw/bin:/usr/gnu/bin gmake test-tier1 1111 | -------------------------------------------------------------------------------- /doc/README.md: -------------------------------------------------------------------------------- 1 | # Documentation 2 | 3 | Here you'll find details how the dobuild script works, how the patches are 4 | laid out, and how this all fits in with porting efforts and jdk development. 5 | 6 | * [The JDK development cycle](jdk-dev-cycle.md) 7 | * [How the code is structured](code-structure.md) 8 | * [How the patches are structured](patch-structure.md) 9 | * [Overview of the porting process](porting-process.md) 10 | * [Running the dobuild script](running-dobuild.md) 11 | -------------------------------------------------------------------------------- /doc/code-structure.md: -------------------------------------------------------------------------------- 1 | # The code layout 2 | 3 | In current releases, you'll largely be interested in 2 parts of the source 4 | tree. 5 | 6 | (In the older days of the mercurial forest the code was laid out quite 7 | differently.) 8 | 9 | ## make 10 | 11 | This is where the various makefiles live. This doesn't change all that much, 12 | but we have to patch the makefiles to add solaris support back (generally, 13 | we have slightly different flags) 14 | 15 | ## src 16 | 17 | The main area is src/hotspot, which is where most of the platform and 18 | architecture specific code resides. There's code for a particular 19 | operating system (os), code for a particular processor (cpu), and for 20 | an operating system running on a give processor (os_cpu). So we're 21 | interested in: 22 | 23 | * os/solaris 24 | * cpu/sparc 25 | * os_cpu/solaris_x86 26 | * os_cpu/solaris_sparc 27 | 28 | We don't need to worry about os/x86, because that's already present and 29 | supported. 30 | 31 | There's also os/posix, which provides a lot of shared code, avoiding the 32 | need for duplicate implementations. There has been a lot of effort to 33 | remove the per-os implementations into posix, which makes life much 34 | easier. (One reason there were different implementations was that each 35 | operating system originally supported was dramatically different. In 36 | 2024 that's not really the case, and everything is close enough to posix 37 | that the code would be essentially the same. In the solaris port we do have 38 | a number of specific implementations, but it's not entirely clear if 39 | they're still necessary - many were due to oddities from decades ago.) 40 | -------------------------------------------------------------------------------- /doc/jdk-dev-cycle.md: -------------------------------------------------------------------------------- 1 | # The JDK development cycle 2 | 3 | JDK is developed on trunk. That's the main jdk development repo. 4 | 5 | Releases are made every 6 months. The majority are intermediate 6 | releases, while some are classed as LTS (Long-Term Support). The LTS 7 | releases are JDK8, JDK11, JDK17, and JDK21. Originally in the new 8 | scheme it was intended to promote every 6th release to LTS (hence 9 | the gap between JDK11 and JDK17) but that was felt to be too long, so 10 | the current aim is every fourth release (so every 2 years). 11 | 12 | ## The cycle of a release 13 | 14 | * JDK XX is developed in the main jdk repository for 6 months, with 15 | a build tag published every week. 16 | 17 | * After 6 months, a stabilisation repo, jdkxx, is created. The main 18 | repository then continues with development of JDK xx+1. 19 | 20 | * Once released (typically another 3 months) the jdkxx repository is 21 | frozen and and updates repository jdkxxu is created. 22 | 23 | You can see this in the naming of the patches. Take jdk16 as an example - 24 | the tags from the main repository are named jdk-jdk-16-14 - the first 25 | component is the repository, the second is always "jdk" as the name of 26 | the project, the third is the version, the last is the build. So you'll 27 | see up to build 26 or 27 (for the 6 month cycle, builds every week). Then 28 | it switches to the tag being jdk16-jdk-16-36 from the jdk16 stabilisation 29 | repository. Typically the last build (the one for GA) is about 35 or 36. 30 | And then you get jdk16u-jdk-16.0.2-7 which is from the jdk16u repository, 31 | update 2, build 7. 32 | 33 | For most releases, you probably get 2 updates. The update cycle matches 34 | Oracle's quarterly CPU (Critical Patch Update) cycle. And those 2 quarterly 35 | updates tide you over the 6 months until the next release. 36 | 37 | Some of the older releases (13 and 15) were supported for longer, as it was 38 | a long time before the next LTS was due. 39 | 40 | The update releases tend not to be managed by Oracle, generally Red Hat 41 | and sometime Azul look after those. 42 | 43 | ## Within a cycle 44 | 45 | Activity varies within a cycle. Clearly within the stabilisation repository 46 | you should see only bugfixes. There will be no new features and very little 47 | churn. 48 | 49 | Things are quiet at the start of a cycle. Imagine that everyone's taking 50 | a breather after the release. 51 | 52 | So most of the churn in terms of new features and big changes occurs at 53 | around the build 20 mark. 54 | 55 | ## Plus or minus? 56 | 57 | In the current github world, the tag will be xx-yy (that's what the tarball 58 | you download will be named and unpack to), but the actual tag will be xx+yy. 59 | 60 | Originally in mercurial both were xx+yy. Some of the older patches were 61 | written for mercurial, and have been switched to the xx-yy convention and 62 | the downloads come from github. 63 | -------------------------------------------------------------------------------- /doc/patch-structure.md: -------------------------------------------------------------------------------- 1 | # How the patches are structured 2 | 3 | The way the patches are structured is, frankly, a bit of a mess. Mostly 4 | this is historical evolution. 5 | 6 | There are essentially 4 types of patches: 7 | 8 | * The gcc port. These are present in all the releases, so you'll see them 9 | all the way back to JDK8. 10 | 11 | * The main removal patch, called java-solaris-sparc.patch. This was 12 | originally the patch for the commit that removed SPARC and Solaris support. 13 | As a result, it's reversed and needs to be applied with -R. 14 | 15 | * Ongoing illumos/Solaris/SPARC support patches, which have been created 16 | to match the ongoing changes to the JDK. 17 | 18 | * The patches to enable a port to zero (an alternate JVM) 19 | 20 | What this means is that in some cases the third class of patches actually 21 | patches things that were patched by earlier patches. More recently I've 22 | tried to avoid that to keep the patching simple. 23 | 24 | The SPARC restoration is a little cleaner. I've removed all of that from 25 | java-solaris-sparc.patch and added the SPARC patches separately. 26 | 27 | ## Cleanliness 28 | 29 | The aim (now) is that the patches apply with zero noise. This means no 30 | fuzz and no line number offsets. This generally makes everything clean, 31 | ensures that no .orig files clutter up the source tree, and also gives 32 | a hint of what files have been changed and might need looking at, because 33 | then you'll see new patch noise. 34 | -------------------------------------------------------------------------------- /doc/porting-process.md: -------------------------------------------------------------------------------- 1 | # The porting process 2 | 3 | As described in the jdk development cycle, a new tag is published every 4 | week. What I do is try and build every tag, so that the scale of changes 5 | is kept small, and you can see what changed. 6 | 7 | ## Try patching 8 | 9 | I apply the patches from the previous tag, and look for noise. If there 10 | are failures, you need to fix them. Any other patch noise is investigated, 11 | as it indicates the file being patched has been modified. The patches 12 | are updated if necessary so that they apply without noise. 13 | 14 | ## Try a build 15 | 16 | One the patching is clean, try a build. 17 | 18 | ## Fix any failures 19 | 20 | If the build fails, any failures need to be fixed. This is where things 21 | get interesting. 22 | 23 | The general approach if something breaks is to look at another platform 24 | (or architecture) to see what's changed between this tag and the previous 25 | successful one. If you get a compilation failure you can see which area (ie 26 | whether it's in os, cpu, or os_cpu) appears affected. Then look at maybe 27 | linux or aix to see what's changed there. 28 | 29 | A lot of the changes I've seen are simple method renaming or signature 30 | changes. In some cases where a new method is added, all you need to do 31 | is provide a stub. If a common method is removed, then check to see if it's 32 | in use anywhere. If it's not it can just be removed; if it's used locally 33 | then maybe you just just move the scope to be local (or os::Solaris). 34 | -------------------------------------------------------------------------------- /doc/running-dobuild.md: -------------------------------------------------------------------------------- 1 | # Running the dobuild script 2 | 3 | The dobuild script is supposed to be reasonably straightforward. A 4 | simple 5 | 6 | ./dobuild jdk17u-jdk-17.0.8-ga 7 | 8 | will download, patch, and build the relevant tag. 9 | 10 | There are several flags you can use. 11 | 12 | With -d, just download the given tag. 13 | 14 | With -p, download if necessary, and apply patches. 15 | 16 | With -b, download if necessary, apply patches, and run a build. 17 | 18 | So, -b is the normal operation. 19 | 20 | The variants -P and -B will delete an existing unpacked copy and start 21 | afresh. 22 | 23 | In practice, what you'll want to do in development is use -p to check 24 | if any new patches apply cleanly, repeat with -P as you develop changes 25 | to the patches, then once you're happy do the build step. 26 | 27 | ## Customizing the build 28 | 29 | You can use the -C flag to pass additional flags to configure, for example 30 | 31 | -C --enable-jvm-feature-management 32 | 33 | You can use the -T flag to specify the type of build, for example 34 | 35 | -T fastdebug 36 | 37 | The available types are release, fastdebug, slowdebug, optimized. The default 38 | is to perform a release build. Apart from enabling some debug flags, the 39 | build type also determines the name of the directory (under build) where the 40 | built jdk will be found. 41 | 42 | The -z flag will pass the appropriate additional flags to the configure 43 | script to build the zero (no-assembler) variant. 44 | 45 | You can use the -k flag to specify an alternate toolchain. The default (and 46 | currently only supported) toolchain is gcc. The options here are limited to 47 | the clang and solstudio toolchains. This flag will only work if there's a 48 | toolchain-specific patch (ie, a patch file named toolchain-clang.patch or 49 | toolchain-solstudio.patch for the jdk version you're trying to build). If 50 | no toolchain-specific patch is found, the build will fail with an error. 51 | There's no guarantee that building with an alternate toolchain will succeed 52 | or generate a functional jdk. 53 | 54 | ## Using a build to compile another 55 | 56 | One part of the process is that you eventually need to use one version of 57 | the JDK in order to build the next. If it finds an installed version it 58 | will use that, but if you're building the whole chain from scratch you 59 | won't have that. So you can use the -i flag, for example 60 | 61 | ./dobuild -i jdk12u-jdk-12.0.2+10 62 | 63 | will make that version of jdk12 available, ready for the jdk13 build. 64 | 65 | ## Exporting a build 66 | 67 | The build process will generate a fully deployable image of the jdk, but it 68 | will be embedded in the build directory. The -i flag above knows where to 69 | find the image for use within another build, but if you want to deploy the 70 | build somewhere else then you'll need a standalone copy. 71 | 72 | You can use the -e flag for this 73 | 74 | ./dobuild -e jdk-jdk-16-24 75 | 76 | will generate a tarball called jdk-jdk-16-24.tar.gz that will unpack into a 77 | directory jdk-jdk-16-24, and will tell you where it's put it. 78 | 79 | ## Patch options 80 | 81 | There are flags to control what patches get applied. 82 | 83 | The -c flag allows you to specify which cpu patches will be applied. By 84 | default, it uses the cpu architecture of the system you're running the 85 | script on. Possible values: sparc 86 | 87 | The -o flag allows you to specify which operating system patches will 88 | be applied. By default, it applies patches appropriate for the system 89 | you're running the script on. Possible values: solaris 90 | 91 | These flags are designed to allow development and testing of patches. 92 | In general, overriding the cpu or os will cause the build to fail. 93 | 94 | The -f flag allows you to apply patches for a specific feature. This 95 | is for any features that might be disabled by default. 96 | 97 | ## Linux support 98 | 99 | There is some support here for running under Linux, specifically Debian 100 | SPARC. A caveat here is that /bin/sh is dash there, so you'll have to 101 | explicitly use bash: 102 | 103 | bash dobuild ... 104 | --------------------------------------------------------------------------------