Building openjdk8 - was Re: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework

[Toby Thain]

On 12/01/15 10:28 AM, David DeHaven wrote:
>
> It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u.
>

Yes. I believe those who have done this on Mavericks (including me) are 
using the apple-gcc4.2 binaries (e.g. the one that brew can install).

--Toby

> -DrD-
>
>> Hello,
>>
>> These changes look ok to me.
>>
>> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build?
>>
>> /Erik
>>
>> On 2015-01-10 05:45, David DeHaven wrote:
>>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.
>>>
>>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.
>>>
>>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.
>>>
>>> For the top level build system:
>>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4
>>> - the LIPO variable was removed since it was completely unused
>>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
>>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)
>>>
>>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.
>>>
>>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.
>>>
>>> JBS Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8043340
>>>
>>> Webrevs:
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk
>>>
>>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.
>>>
>>> -DrD-
>>>
>>
>
>