[8u] RFR 8226288 - Upgrade to XCode 10+ for building JDK 8u and 11u

Simon Tooke stooke at redhat.com
Fri Feb 28 13:36:08 UTC 2020


On 2020-02-28 4:14 a.m., Vladimir Kempik wrote:
> Hello
>
> Are you sure it’s needed for jdk8 ?

The intent isn't to replace gcc builds with clang builds at this time.  
It's to make 8u more accessible for developers to work on. Xcode 4 
doesn't run on the latest versions of macos, and I doubt that the latest 
Apple hardware runs a version of macos that supports it.

JDK8 will be supported for quite a few year to come, and I believe once 
the issues with Clang are worked out it may become the preferred 
production build, but not yet.

>
> Notarization requires sdk of version at least 10.9
>
> This can be achieved using xcode 4.3.x together with 10.9 sdk (either 
> copy 10.l9 sdk from xcode5 or use systemwide sdk if build host is 
> 10.9) and patching two lines in jdk8’s make files.
This is not really a solution long term; see above.  This may work for 
notarization
>
> Going to clang may have many undesired consequences, for example 
> https://bugs.openjdk.java.net/browse/JDK-8234963

Yes, there are other issues too.  I would argue that adding clang 
buildability to jdk8 increases the pool of developers that can work to 
improve both jdk8 and LLVM.

>
> Example of the patch to build jdk8 with gcc-llvm and sdk 10.9:
This doesn't meet the goals of my RFR, which is to add the ability to 
build a reasonable quality macos JDK8 with the latest toolchain, and 
then improve the quality with later backports as they are found.
>
> hotspot:
> $ hg diff
> *diff -r 3c35d9ae7194 make/bsd/makefiles/gcc.make*
> *--- a/make/bsd/makefiles/gcc.make       Thu Feb 20 15:54:10 2020 +0300*
> *+++ b/make/bsd/makefiles/gcc.make       Wed Feb 26 14:06:16 2020 +0300*
> @@ -344,7 +344,7 @@
> # if built on a newer version of the OS.
> # The expected format is X.Y.Z
> ifeq ($(MACOSX_VERSION_MIN),)
> -    MACOSX_VERSION_MIN=10.7.0
> +    MACOSX_VERSION_MIN=10.9.0
> endif
> # The macro takes the version with no dots, ex: 1070
> CFLAGS += -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst 
> .,,$(MACOSX_VERSION_MIN)) \
> os-x-10:hotspot dmitry$ cd ..
> $ hg diff
> *diff -r d8c00a997c65 common/autoconf/flags.m4*
> *--- a/common/autoconf/flags.m4  Thu Feb 20 15:54:10 2020 +0300*
> *+++ b/common/autoconf/flags.m4  Wed Feb 26 14:06:22 2020 +0300*
> @@ -633,7 +633,7 @@
>     # newer than the given OS version and makes the linked binaries 
> compatible
>     # even if built on a newer version of the OS.
>     # The expected format is X.Y.Z
> - MACOSX_VERSION_MIN=10.7.0
> + MACOSX_VERSION_MIN=10.9.0
>     AC_SUBST(MACOSX_VERSION_MIN)
>
>
>     # The macro takes the version with no dots, ex: 1070
> *diff -r d8c00a997c65 common/autoconf/generated-configure.sh*
> *--- a/common/autoconf/generated-configure.sh    Thu Feb 20 15:54:10 
> 2020 +0300*
> *+++ b/common/autoconf/generated-configure.sh    Wed Feb 26 14:06:22 
> 2020 +0300*
> @@ -4396,7 +4396,7 @@
>  #CUSTOM_AUTOCONF_INCLUDE
>
>
>  # Do not change or remove the following line, it is needed for 
> consistency checks:
> -DATE_WHEN_GENERATED=1580709484
> +DATE_WHEN_GENERATED=1582708947
>
>
>  ###############################################################################
>  #
> @@ -42159,7 +42159,7 @@
>     # newer than the given OS version and makes the linked binaries 
> compatible
>     # even if built on a newer version of the OS.
>     # The expected format is X.Y.Z
> - MACOSX_VERSION_MIN=10.7.0
> + MACOSX_VERSION_MIN=10.9.0
>
>
>
>     # The macro takes the version with no dots, ex: 1070
>
> Thanks, Vladimir
>
>> 13 сент. 2019 г., в 17:05, Simon Tooke <stooke at redhat.com 
>> <mailto:stooke at redhat.com>> написал(а):
>>
>> Hello all,
>>
>> This is a request for review of my patch to enable building 8u with
>> modern (9,10,11) Xcode versions on macOS.  I've received a few recent
>> enquiries so I thought I'd submit this.
>>
>> When I first created this patch is was more for convenience, but soon
>> macOS will require applications to be "notarized", which cannot be done
>> with the old version of Xcode.  This will become mandatory long before
>> 8u is due to retire [1].
>>
>> This patch is not intended to remove the current ability to build 8u on
>> the current supported build platform.
>>
>> I have used the patch with Xcode 9,10 and a beta of 11, and used the
>> resultant JDK to build Graal.
>>
>> I have not build a JDK using the old Xcode and this patch; my intent was
>> to ensure this was still possible.
>>
>> There is some information available on my GitHub page:
>> https://github.com/stooke/jdk8u-xcode10
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8226288
>>
>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8226288-jdk8u/00/
>>
>> Previous discussion:
>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009733.html
>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009760.html
>>
>> Thank you for your time,
>>
>> -Simon
>>
>>
>> [1]
>> https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
>



More information about the build-dev mailing list