Mac devkit requires changes for XCode 26

[Erik Joelsson]

Hello Galder,

At Oracle we use this script to generate new devkits every time we 
update the toolchains we use for official builds, so it should be up to 
date and working for the latest toolchain we use at least, which at this 
time is Xcode 15.4. We have not yet jumped to Xcode 26, but when we do, 
we will make the script work unless someone else beats us to it.

The expectation when running the script should not be to first have to 
copy things around in the installation directory of Xcode. The script 
should handle this automatically. However, it could be that we need to 
supply a path to both Xcode and metal going forward. I have not looked 
into this at all yet.

/Erik

On 11/27/25 04:20, Galder Zamarreno wrote:
> Hi,
>
> I'm wondering what's the objective of the Mac devkit and how much is it
> being kept up to date.
>
> I've been finding it useful to create a devkit that works for me to
> build the jdk inside a Nix shell on a mac. Nix shells easily allow me to
> capture all the dependencies building jdks have (e.g. capstone) in a
> reproducable way independent of global installations at the mac level.
>
> With the latest XCode 26 and Metal separation, I've been finding that
> the current mac devkit is not fully suited for this changes.
>
> As you might have seen in [1], Metal is no longer part of XCode 26 and
> now needs to be installed separately. The location where Metal gets
> installed by default is not inside /Applications/XCode.app but a rather
> different place. On my system this is:
>
> ```
> % xcrun --find metallib
> /var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.2.54.0.mgWMUd/Metal.xctoolchain/usr/bin/metallib
> ```
>
> To be able to carry on building the JDK on a Nix shell, I manually moved
> the Metal.xctoolchain folder to
> /Applications/Xcode.app/Contents/Developer/Toolchains and then invoked
> the mac devkit script.
>
> This alone however was not enough to get the jdk to build, but the XCode
> 26 itself does have the `metal` executable and the jdk was picking it
> up. So, on top of that manual move, I tweaked the
> `DEVKIT_TOOLCHAIN_PATH` so that the Metal binaries would resolve out of
> the Metal.xctoolchain/usr/bin folder:
>
> ```
> echo-info "DEVKIT_TOOLCHAIN_PATH=\"\$DEVKIT_ROOT/Xcode/Contents/Developer/Toolchains/Metal.xctoolchain/usr/bin:\$DEVKIT_ROOT/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:\$DEVKIT_ROOT/Xcode/Contents/Developer/usr/bin\""
> ```
>
> After doing this I rebuilt the devkit and I was able to build the jdk
> once again inside a Nix shell on mac.
>
> Of course, the devkit could have been modified to avoid the need for the
> manual move and instead resolve the `/var/run/...` folder. But I do
> wonder how much this devkit really is kept up to date and what's the use
> case that ended up creating it.
>
> Thanks
> Galder
>
> [1] https://bugs.openjdk.org/browse/JDK-8372393
> [2] https://medium.com/%40sergey-pekar/how-to-fix-annoying-xcode-26-not-building-swiftui-previews-error-cannot-execute-tool-metal-due-49564e20357c
> --
> Galder Zamarreño
> Software Developer
> IBM Software
> galder at ibm.com
>
> IBM