RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
Erik Joelsson
erik.joelsson at oracle.com
Tue Jul 11 09:45:40 UTC 2017
The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are
used in combination to achieve the same thing. I chose to use both to
really enforce full compatibility with the specified version. The
"official" way of targeting earlier versions of the OS is just using
-mmacosx-version-min. This will however still accept uses of newer APIs,
but at link time, those will be linked with weak_import. Essentially
it's expected that your application should be able to do without these
calls if necessary, at the application level. While better than not
being able to launch at all on the older OS, by adding
-DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any
code tries to use a newer API.
As I see it, either we fully enforce this at build time, or we don't at
all. The natural default is to build for the current host platform. The
configure parameter would make it possible to enforce a minimal
compatible OS version that the binaries must be usable on.
(Note that if you propose such a change, I will need to add the Oracle
bit as well, where we use the parameter, which would need to go in at
the same time in common/conf/jib-profiles.js. Also note that I will be
on vacation for 5 weeks starting this weekend so won't be around to
review for most of that time.)
/Erik
On 2017-07-10 19:48, Hohensee, Paul wrote:
> That’s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there’s likely a lot of code that depends on it. Let me see what I can come up with.
>
> Thanks,
>
> Paul
>
> On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>
>
>
> On 2017-07-10 18:09, Hohensee, Paul wrote:
> > Hi Erik,
> >
> > The problem is that the compiler doesn’t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can’t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
> >
> > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can’t use them to do JDK development.
> That's not exactly true. Apple is making it very hard to stay on older
> versions of the OS compared to other OS vendors. For this reason we are
> not always able to stay on a particular version for Macosx in
> particular. We also in general try to avoid having to fill our build
> servers/environments with just the oldest OSes, because older OSes are
> harder to maintain and less convenient to work with. So instead, we try
> to maintain working build environments on newer OSes that produce
> binaries that are compatible with the oldest we support. So, at least
> from Oracle's perspective, we prefer if builds on different OS versions
> produce equivalent binaries when possible. We certainly don't want to
> prevent building on newer OS/compilers.
>
> If this can't be worked around at the source level, then perhaps we need
> to consider hiding this macro definition behind a configure option that
> we can use internally. I would be open to that. Something like
> --with-macosx-version-min=10.7 which configure could then translate to
> the combination of options currently used. That way, most openjdk
> developers/builders would not need to suffer this Oracle requirement.
>
> /Erik
> > Thanks,
> >
> > Paul
> >
> > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
> >
> > Hello,
> >
> > I do not agree to removing that macro. I added those options to help
> > guarantee that a build made on a newer version of macosx would still run
> > on the oldest version currently supported. The macro is not mainly meant
> > to be used in our code, but is picked up by system headers to cause an
> > error if any features newer than 10.7 are used. It may be that we should
> > bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
> >
> > It seems to me that we instead need to ignore the particular warning for
> > this case.
> >
> > /Erik
> >
> >
> > On 2017-07-09 15:26, Hohensee, Paul wrote:
> > > Please review the following change to get JDK10 to build on OSX 10.12 and above.
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8184022
> > > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
> > >
> > > I’d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
> > >
> > > Slightly revised from the RFE:
> > >
> > > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
> > >
> > > #if defined(MAC_OS_X_VERSION_10_12) && \
> > > MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
> > > __LP64__
> > > / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
> > > - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
> > > #else
> > > - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
> > > #endif
> > > untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
> > >
> > > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
> > >
> > > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
> > >
> > > Thanks,
> > >
> > > Paul
> > >
> >
> >
> >
>
>
>
More information about the build-dev
mailing list