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.joels...@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.joels...@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
    >      >
    >      
    >      
    >
    
    

Reply via email to