Or rather, the point of this exercise is to eliminate the hacks to get it to
build with Xcode 5 (I'm not sure if anyone was truly successful with that).
It's far better to just build with Xcode 4.6.3, and with these changes you
don't even need to pre-sanitize your Xcode environment.
A proper build setup would have Xcode 5 or 6 installed in
/Applications/Xcode.app (generally MAS managed) and Xcode 4.6.3 (still
available for download on ADC) somewhere NOT directly in /Applications (the Mac
App Store has a nasty habit of "upgrading" it when it sees it there). I keep
mine in /Applications/old along with a copy of Xcode 5.1.1 for test purposes.
The --with-xcode-path argument is optional, you should also be able to build
with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I
leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between
projects and it's a hassle to have to remember to reset the active toolchain,
so I thought it best to allow configure to be provided a path.
I'm kind of bummed I didn't get to show my really nasty hack for working around
the broken lipo stub tool, it was so horrible it could be considered artwork! :)
-DrD-
> It won't build at all with Xcode 5, there is no gcc compiler and the clang
> changes were never backported to jdk8u.
>
> -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-
>>>
>>
>
