minimal backport of 8182299 build on OSX 10 + Xcode 8
Simon Tooke
stooke at redhat.com
Thu Jul 4 13:22:23 UTC 2019
On 7/3/2019 4:50 PM, Hohensee, Paul wrote:
> There are quite a few JBS issues that fix gcc 7 and 8 compilation problems. Possibly backporting these will fix most/all of clang's complaints as well.
I would prefer to address compiler warnings sepaately; they are a really
big rabbit hole.
In fact, I'd rather address runtime undefined behaviours first; fixing
these often fixes compile-time warnings too.
-Simon
>
> Paul
>
> On 7/3/19, 1:33 PM, "jdk8u-dev on behalf of Simon Tooke" <jdk8u-dev-bounces at openjdk.java.net on behalf of stooke at redhat.com> wrote:
>
>
> On 7/3/2019 4:03 PM, Andrew John Hughes wrote:
> >
> > On 03/07/2019 19:30, Ben Evans wrote:
> >> Hi,
> >>
> >> As this appears to have been Warnock'd (
> >> https://en.wikipedia.org/wiki/Warnock%27s_dilemma), allow me to give it
> >> another kick.
> >>
> >> My personal take (for the little that it's worth) is: Given current
> >> adoption rates and trends, JDK 8 is going to be with us for a long time.
> >> Restricting the potential community size of developers working on OpenJDK 8
> >> by:
> >>
> >> 1.) Requiring that people who develop on Macs jump through virtualisation
> >> hoops and
> >> 2.) Making the building of binaries a byzantine process requiring the
> >> maintenance of obsolete Macs
> >>
> >> is bad, and we should stop doing it.
> >>
> >> Thanks,
> >>
> >> Ben
> >>
> >> On Fri, Jun 28, 2019 at 4:09 PM Simon Tooke <stooke at redhat.com> wrote:
> >>
> >>> Hello everyone,
> >>>
> >>> I would like to make a somewhat controversial proposal: to backport the
> >>> minimal changes required to enable jdk8u to compile and run when built
> >>> with the latest macOS developer tools.
> >>>
> >>> I realize this falls outside of aph's guidelines of "bug fixes only,
> >>> (for now)" and in many ways is only a developer convenience, since I am
> >>> not advocating (at this time) for this build to become the default
> >>> supported for macOS [1].
> >>>
> >>> There changes do not affect the current mac build, which requires an old
> >>> version of Xcode which doesn't run on modern releases of macOS, but they
> >>> make it much easier for macOS hackers to work with jdk8.
> >>>
> >>> At this point, testing has been confined to bootstrapping the build with
> >>> a jdk8 built using this patch, and to using this build to build a
> >>> working Graal substrateVM.
> >>>
> >>> My version of the backport limits the scope of the 8182299 patches to
> >>> the subset required to get the JDK up and running. I don't propose
> >>> backporting any changes to remove Clang warnings, etc. Because of that,
> >>> my changes are confined in scope.
> >>>
> >>> Potential long term benefits (if this build does seem healthy enough for
> >>> production) are simplified macOS build platforms, a more modern compiler
> >>> and perhaps higher performance.
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182656
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/xcodemacos.webrev/
> >>>
> >>> Thanks for your time,
> >>>
> >>> -Simon
> >>>
> >>> [1] first, potentially removes support for macOS 10.8, second, needs
> >>> more testing.
> >>>
> >>>
> >>>
> > I saw it, but there's a CPU on right now. I'll have a look properly once
> > that's out of the way.
> Yes, I know this is very much on the back burner for now.
> > My initial thought is what is the subset you refer to? The problem with
> > backporting bits of a change is that it then looks like that change is
> > backported, but some parts of it are actually missing.
>
> We could avoid referring to the initial patch altogether; a large part
> of it (which I avoided) was simply getting rid of clang warning
> messages. I just went for the bits that stop the crash, and skipped the
> rest.
>
>
>
>
>
More information about the jdk8u-dev
mailing list