Apple: Update to Apple 26.0 SDKs; patch llvm-project/release/21; add swift toolchain #155

stuartcarnie · 2025-10-05T07:00:07Z

This PR:

Updates to the latest Xcode version
Installs the swift 6.2 toolchain for macOS and Apple embedded containers
Updates to llvm 21

iOS Build Status

✅ iOS successfully builds with Swift source additions

visionOS Build Status

❌ visionOS does not build, because of Clang does not process visionOS (xros) availability correctly swiftlang/llvm-project#10782, and is the same problem that I patched for compiling C / C++ / Objective-C / Objective-C++

When the swift compiler attempts to compile modules that have the same availability checks as is mentioned in swiftlang/llvm-project/issues/10782, it fails due to the bug in llvm

In order to resolve this, the Swift 6.2 toolchain will need to be compiled with the same patched llvm-project toolchain.

akien-mga

Looks pretty good! I haven't had time to test yet.

Dockerfile.appleembedded

Dockerfile.osx

build.sh

akien-mga · 2025-10-10T12:18:59Z

extract_xcode_sdks.sh

    echo "=== Copying SDK using tar to preserve special files ==="
    cd "$sdk_dir"
-    tar -cf - "$sdk_name" | (cd "/tmp" && tar -xf -)
+    tar -cf - "$sdk_name" | tar -xf - -C /tmp


That's a pre-existing issue, but we should make use mktemp -d instead of just unarchiving in /tmp.

akien-mga · 2025-10-10T12:20:52Z

If I understand correctly we'll need this to be able to build iOS templates for 4.6-dev2, so this can likely be merged as is and improved in a follow-up PR. I won't be around next week to work on this.

Dockerfile.osx

akien-mga · 2025-10-10T20:10:13Z

Dockerfile.xcode

 ENV OSX_SDKV=
 ENV IOS_SDKV=
 ENV TVOS_SDKV=


I think these can be removed.

akien-mga · 2025-10-10T20:10:36Z

Dockerfile.osx

+
+ENV XCODE_SDKV=26.0.1
+ENV APPLE_SDKV=26.0
+ENV OSX_SDK=26.0


Could be removed and replaced by APPLE_SDKV below.

stuartcarnie · 2025-10-12T21:59:41Z

I will verify it works from a .xip; I manually extracted Xcode and referenced that, so perhaps there is an issue with that step?

stuartcarnie · 2025-10-13T07:10:27Z

@akien-mga I've pushed up a separate Dockerfile.swift for you to test, that just runs the Swift steps. Can you try that and see what happens, after you have downloaded and prepared the Xcode SDK

img_version=4.6-f42 podman build --build-arg img_version=${img_version} -v $(realpath files):/root/files:z -t godot-swift:${img_version} -f Dockerfile.swift .

Here is the tail of my output from that command:

99%: Downloaded 940.6 MiB of 942.5 MiB
100%: Downloaded 942.5 MiB of 942.5 MiB
Verifying toolchain signature...
Extracting toolchain...
The global default toolchain has been set to `Swift 6.2.0`
Swift 6.2.0 is installed successfully!
--> 0fe45dffc24f
STEP 9/11: RUN /root/files/swift/create-sdk-bundle.sh /root/Xcode.app/Contents/Developer /root/swift-sdk
Creating artifact bundle at /root/swift-sdk/darwin.artifactbundle
Found SDKs:
  iOS: iPhoneOS26.0.sdk
  iOS Sim: iPhoneSimulator26.0.sdk
  macOS: MacOSX26.0.sdk
  tvOS: AppleTVOS26.0.sdk
  tvOS Sim: AppleTVSimulator26.0.sdk
  visionOS: XROS26.0.sdk
  visionOS Sim: XRSimulator26.0.sdk
--> 22bc3c3a7536
STEP 10/11: RUN PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle
Swift SDK bundle at `/root/swift-sdk/darwin.artifactbundle` successfully installed as darwin.artifactbundle.
--> a14b84bea872
STEP 11/11: CMD /bin/bash
COMMIT godot-swift:4.6-f42
--> b0859dcac840
Successfully tagged localhost/godot-swift:4.6-f42
b0859dcac8403825b1061270ea6b61ee7cf4cee9507990c9cbfce9d0f8f25094

akien-mga · 2025-10-13T18:49:27Z

Same error with the new dockerfile sadly:

99%: Downloaded 945.7 MiB of 954.4 MiB
100%: Downloaded 954.4 MiB of 954.4 MiB
Verifying toolchain signature...
Extracting toolchain...
The global default toolchain has been set to `Swift 6.2.0`
Swift 6.2.0 is installed successfully!
--> c734eb77d4ca
STEP 9/11: RUN /root/files/swift/create-sdk-bundle.sh /root/Xcode.app/Contents/Developer /root/swift-sdk
Creating artifact bundle at /root/swift-sdk/darwin.artifactbundle
Found SDKs:
  iOS: iPhoneOS26.0.sdk
  iOS Sim: iPhoneSimulator26.0.sdk
  macOS: MacOSX26.0.sdk
  tvOS: AppleTVOS26.0.sdk
  tvOS Sim: AppleTVSimulator26.0.sdk
  visionOS: XROS26.0.sdk
  visionOS Sim: XRSimulator26.0.sdk
--> 6527a06741da
STEP 10/11: RUN PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle
Error: Error Domain=NSCocoaErrorDomain Code=512 "(null)"UserInfo={NSDestinationFilePath=/root/.swiftpm/swift-sdks/darwin.artifactbundle, NSUserStringVariant=["Copy"], NSSourceFilePathErrorKey=/root/swift-sdk/darwin.artifactbundle, NSURL=file:///root/swift-sdk/darwin.artifactbundle, NSFilePath=/root/swift-sdk/darwin.artifactbundle}
Error: building at STEP "RUN PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle": while running runtime: exit status 1

I'm running on a Fedora 42 host for the record, and with sudo but I don't expect this to impact the behavior.

stuartcarnie · 2025-10-13T21:01:27Z

I'm running on a Fedora 42 host for the record, and with sudo but I don't expect this to impact the behavior.

Did some more research, and apparently sudo could be impacting things. One suggestion is to add the --no-same-owner, which I have done when extracting the Xcode tar.gz. Can you try the Dockerfile.swift again?

akien-mga · 2025-10-15T21:26:18Z

Still no luck with the latest commit:

$ export img_version=4.6-f42 
$ sudo podman build --build-arg img_version=${img_version} -v $(realpath files):/root/files:z -t godot-swift:${img_version} -f Dockerfile.swift .
STEP 1/11: FROM godot-fedora:4.6-f42
STEP 2/11: ENV XCODE_SDKV=26.0.1
--> Using cache 4d52f7bd9cef0b35f7f5bdbeca6ff31edf53db6223e8a18265131cb57143678d
--> 4d52f7bd9cef
STEP 3/11: ENV APPLE_SDKV=26.0
--> Using cache 05fbcdc16ef590b9411b45e7dd5dcfa1046fe5bf449f6ab6706d711e6ccae696
--> 05fbcdc16ef5
STEP 4/11: ENV OSX_SDK=26.0
--> Using cache bb7d734c7ea57fe9281b0c4b700a7b2edc336bca6b3eaecf91055731b3c33b76
--> bb7d734c7ea5
STEP 5/11: RUN dnf -y install --setopt=install_weak_deps=False     gpg
--> Using cache 2fd7d8b19404b7a5fd2fb726f39a6e37da787fe1c50341ce3c26be09586f1881
--> 2fd7d8b19404
STEP 6/11: RUN mkdir -p /root/Xcode.app/Contents/Developer
--> Using cache 2dccfda00ec012b7852ec28aae3e719ab88328135418afc34b0b7ee7abcbd18a
--> 2dccfda00ec0
STEP 7/11: RUN cd /root/Xcode.app/Contents/Developer && tar xf /root/files/Xcode-Developer${XCODE_SDKV}.tar.xz --strip-components=1 --no-same-owner
--> Using cache 64182744063c827ef19fb798705809399550687e2223449129723415d851ff9e
--> 64182744063c
STEP 8/11: RUN curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz &&     tar zxf swiftly-$(uname -m).tar.gz &&     ./swiftly init --platform ubi9 --quiet-shell-followup -y &&     . "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" &&     hash -r
--> Using cache 3dfcc7d4e670cf73773777189e7b343027c8f58aa6818030a6d82e52f1212aec
--> 3dfcc7d4e670
STEP 9/11: RUN /root/files/swift/create-sdk-bundle.sh /root/Xcode.app/Contents/Developer /root/swift-sdk
--> Using cache 898d153f6aae096709b7dabb133a772651f0520d234adef2deaeb4bd7393e1f2
--> 898d153f6aae
STEP 10/11: RUN PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle
Error: Error Domain=NSCocoaErrorDomain Code=512 "(null)"UserInfo={NSUserStringVariant=["Copy"], NSURL=file:///root/swift-sdk/darwin.artifactbundle, NSDestinationFilePath=/root/.swiftpm/swift-sdks/darwin.artifactbundle, NSSourceFilePathErrorKey=/root/swift-sdk/darwin.artifactbundle, NSFilePath=/root/swift-sdk/darwin.artifactbundle}
Error: building at STEP "RUN PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle": while running runtime: exit status 1

stuartcarnie · 2025-10-15T22:28:40Z

@akien-mga I am running the podman container under Ubuntu; do you think there are differences between the OSs as to why it is failing for you? The other difference is that your container is running as x86_64 and mine is arm64. I don't see why the architecture should matter, but it is a difference.

It's slightly amusing that we're using containers to avoid conflicts from the local machine, yet here we are…

akien-mga · 2025-10-15T22:39:57Z

For the record, I made a test build without sudo and I ran into the same issue.

@akien-mga I am running the podman container under Ubuntu; do you think there are differences between the OSs as to why it is failing for you? The other difference is that your container is running as x86_64 and mine is arm64. I don't see why the architecture should matter, but it is a difference.

It's slightly amusing that we're using containers to avoid conflicts from the local machine, yet here we are…

Yeah there's probably some system configuration difference or some of the underlying stack for podman that may differ between Fedora and Ubuntu. We might need advice from @hpvb to debug this.

stuartcarnie · 2025-10-15T22:58:21Z

@akien-mga I am going to set up a Fedora 42 x86_64 host VM and run podman inside that to match your environment as closely as possible. I'll also extract Xcode from the 26.0.1 .xip and see how I go.

stuartcarnie · 2025-10-15T23:09:23Z

@akien-mga I'm now at a loss, as I set up an environment that very closely models yours:

Fedora 42 x86_64 host machine
sudo podman ... invocations

Important

What version of podman are you running, as apparently there are bugs in 4.x regarding symbolic links:

podman --version

podman version 5.6.2

Run godot-xcode to extract SDK from 26.0.1 .xip file (using Xcode_26.0.1_Apple_silicon.xip)

sudo podman run -it --rm -v $(realpath files):/root/files:z -v /Volumes/Data:/root/data:z -e XCODE_SDKV=26.0.1 -e XCODE_XIP_PATH=/root/data/Xcode_26.0.1_Apple_silicon.xip -e APPLE_SDKV=26.0 godot-xcode:${img_version}

Run Dockerfile.swift to test (which is now running the x86_64 binary)

sudo podman build --build-arg img_version=${img_version} -v $(realpath files):/root/files:z -t godot-swift:${img_version} -f Dockerfile.swift .

97%: Downloaded 935.2 MiB of 954.4 MiB
99%: Downloaded 946.4 MiB of 954.4 MiB
100%: Downloaded 954.4 MiB of 954.4 MiB
Verifying toolchain signature...
Extracting toolchain...
The global default toolchain has been set to `Swift 6.2.0`
Swift 6.2.0 is installed successfully!
--> 7d7ea339863e
STEP 9/11: RUN /root/files/swift/create-sdk-bundle.sh /root/Xcode.app/Contents/Developer /root/swift-sdk
Creating artifact bundle at /root/swift-sdk/darwin.artifactbundle
Found SDKs:
  iOS: iPhoneOS26.0.sdk
  iOS Sim: iPhoneSimulator26.0.sdk
  macOS: MacOSX26.0.sdk
  tvOS: AppleTVOS26.0.sdk
  tvOS Sim: AppleTVSimulator26.0.sdk
  visionOS: XROS26.0.sdk
  visionOS Sim: XRSimulator26.0.sdk
--> e82c6c95e0de
STEP 10/11: RUN PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle
Swift SDK bundle at `/root/swift-sdk/darwin.artifactbundle` successfully installed as darwin.artifactbundle.
--> 1007cb68dcd6
STEP 11/11: CMD /bin/bash
COMMIT godot-swift:4.6-f42
--> 96828fcea0ef
Successfully tagged localhost/godot-swift:4.6-f42
96828fcea0efd4adfde1670d4257061af46b5dd481b068da8d25b7291d386c73

stuartcarnie · 2025-10-16T18:15:25Z

@akien-mga could I build the Apple containers for you and push them to a repository, so you can pull them down?

akien-mga · 2025-10-16T19:30:54Z

@akien-mga could I build the Apple containers for you and push them to a repository, so you can pull them down?

That could work as a stopgap measure, but the purpose of these containers is to be reproducible, and they're not just used by us for our builds but potential other users who want to make their custom builds of Godot. So if this PR only works on some machines we need to figure out why and solve that.

HP started looking into it to see what might cause this difference in behavior.

If we can't find how to make it work quickly, I would likely prefer that we temporarily revert the PR that made Swift a requirement for iOS and visionOS, so we can build 4.6-dev2 (this is currently the main blocker to making new builds). Then we can take our time to ensure that the build pipeline is ready for it before merging it again.

stuartcarnie · 2025-10-16T23:48:20Z

That could work as a stopgap measure, but the purpose of these containers is to be reproducible, and they're not just used by us for our builds but potential other users who want to make their custom builds of Godot. So if this PR only works on some machines we need to figure out why and solve that.

Absolutely agree! It baffles me that I've set up a mostly similar environment to you and still can't reproduce it. The supposed benefit of containers is to avoid host incompatibilities 😅

If we can't find how to make it work quickly, I would likely prefer that we temporarily revert the PR that made Swift a requirement for iOS and visionOS, so we can build 4.6-dev2 (this is currently the main blocker to making new builds). Then we can take our time to ensure that the build pipeline is ready for it before merging it again.

No problem at all and the right decision if we can't resolve it.

stuartcarnie · 2025-10-16T23:49:03Z

HP started looking into it to see what might cause this difference in behavior.

If HP needs anything from me, don't hesitate to ping me.

hpvb · 2025-10-17T13:19:25Z

The error is cosmetic

After a successful run of the script:

# PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle
Swift SDK bundle at `/root/swift-sdk/darwin.artifactbundle` successfully installed as darwin.artifactbundle.
# find ~/.swiftpm/swift-sdks/ -type f -exec md5sum {} \;
8951d37616b815827c2512116d0fe33f  /root/.swiftpm/swift-sdks/darwin.artifactbundle/info.json
b32fb0e3eea29096e1661992b80f7e7e  /root/.swiftpm/swift-sdks/darwin.artifactbundle/swift-sdk.json
54f0b7f20ec29b9cf09c3cc0a0652ead  /root/.swiftpm/swift-sdks/darwin.artifactbundle/toolset.json

An unsuccessful run:

# PATH="/root/.local/share/swiftly/bin:${PATH}" swift sdk install /root/swift-sdk/darwin.artifactbundle
Error: Error Domain=NSCocoaErrorDomain Code=512 "(null)"UserInfo={NSFilePath=/root/swift-sdk/darwin.artifactbundle, NSDestinationFilePath=/root/.swiftpm/swift-sdks/darwin.artifactbundle, NSURL=file:///root/swift-sdk/darwin.artifactbundle, NSUserStringVariant=["Copy"], NSSourceFilePathErrorKey=/root/swift-sdk/darwin.artifactbundle}
# find ~/.swiftpm/swift-sdks/ -type f -exec md5sum {} \;
8951d37616b815827c2512116d0fe33f  /root/.swiftpm/swift-sdks/darwin.artifactbundle/info.json
b32fb0e3eea29096e1661992b80f7e7e  /root/.swiftpm/swift-sdks/darwin.artifactbundle/swift-sdk.json
54f0b7f20ec29b9cf09c3cc0a0652ead  /root/.swiftpm/swift-sdks/darwin.artifactbundle/toolset.json

The contents are identical (the symbolic link also points to the same place)

The root cause is this:

110   openat(AT_FDCWD, "/root/.swiftpm/swift-sdks/darwin.artifactbundle", O_RDONLY|O_NOFOLLOW|O_DIRECTORY) = 10
....
110   fsetxattr(10, "security.selinux", "system_u:object_r:container_file"..., 48, 0) = -1 EOPNOTSUPP (Operation not supported)

Probably because the buildsystem has selinux enabled (it is, however, in permissive mode), or because we use a different filesystem than you @stuartcarnie the swift installer thinks that it can run fsetxattr on the directory in /root. But because this is an overlayfs this cannot work.

the swift installed will then give up, even though it seems to have done all it is ever going to do.

The 'fix' for this I suppose is to ignore this error, I would suggest doing a grep on stderr to ensure that the error that is being ignored is in fact the error we are 'expecting' in this case.

EDIT: Alternatively, just don't use the script at all, and manually copy /root/swift-sdk/darwin.artifactbundle/ to /root/.swiftpm/swift-sdks/darwin.artifactbundle

This appears all that swift sdk install does in our case. Presumably the step /root/files/swift/create-sdk-bundle.sh /root/Xcode.app/Contents/Developer /root/swift-sdk can also just directly place the sdk files in the correct place, saving an entire step.

stuartcarnie · 2025-10-17T18:38:11Z

@hpvb great – I'll just try copy the files, as you are right, that is probably all it is doing.

stuartcarnie · 2025-10-17T18:58:26Z

@akien-mga I've pushed up the changes and verified I could still build an iOS object file using Swift. No longer uses swift to install the SDK

akien-mga

It seems to work well now.

There are still a few SDK-specific variables like IOS_SDKV/VISIONOS_SDKV/etc. that could be streamlined now that there's only one APPLE_SDKV, but this can be done in a follow-up cleanup. The priority now is to have functional build containers.

Thanks a lot for the great work @stuartcarnie, and thanks @hpvb for the help debugging the copy issue.

This was referenced Oct 5, 2025

Apple: Update to Apple 26.0 SDKs godotengine/godot-build-scripts#129

Merged

Build: Fix container build path for swift godotengine/godot#111299

Merged

stuartcarnie force-pushed the apple-sdks branch 2 times, most recently from 18acd40 to 0144815 Compare October 7, 2025 21:54

akien-mga reviewed Oct 10, 2025

View reviewed changes

Dockerfile.osx Outdated Show resolved Hide resolved

stuartcarnie force-pushed the apple-sdks branch from 0144815 to c19f8b4 Compare October 10, 2025 19:31

akien-mga reviewed Oct 10, 2025

View reviewed changes

Dockerfile.osx

ENV XCODE_SDKV=26.0.1

ENV APPLE_SDKV=26.0

ENV OSX_SDK=26.0

Copy link

Member

akien-mga Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be removed and replaced by APPLE_SDKV below.

stuartcarnie force-pushed the apple-sdks branch from c19f8b4 to 2df1f94 Compare October 13, 2025 07:08

stuartcarnie force-pushed the apple-sdks branch from 2df1f94 to ce13ef7 Compare October 13, 2025 20:59

Calinou added the enhancement New feature or request label Oct 14, 2025

stuartcarnie force-pushed the apple-sdks branch from ce13ef7 to 40fed86 Compare October 17, 2025 18:57

Apple: Update to Apple 26.0 SDKs

4b58ce1

stuartcarnie force-pushed the apple-sdks branch from 40fed86 to 4b58ce1 Compare October 17, 2025 20:26

akien-mga approved these changes Oct 18, 2025

View reviewed changes

akien-mga merged commit 277982a into godotengine:main Oct 18, 2025

akien-mga mentioned this pull request Oct 18, 2025

Temporarily disable visionOS builds as we lack a build container with compatible Swift SDK godotengine/godot-build-scripts#133

Merged

stuartcarnie deleted the apple-sdks branch October 18, 2025 19:15

stuartcarnie mentioned this pull request Oct 18, 2025

Build: Update to Xcode 26.0.1 for Apple builds godotengine/godot#111799

Merged

Uh oh!

Apple: Update to Apple 26.0 SDKs; patch llvm-project/release/21; add swift toolchain #155

Apple: Update to Apple 26.0 SDKs; patch llvm-project/release/21; add swift toolchain #155

Conversation

stuartcarnie commented Oct 5, 2025

iOS Build Status

visionOS Build Status

Uh oh!

akien-mga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

akien-mga Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

akien-mga commented Oct 10, 2025

Uh oh!

Uh oh!

akien-mga Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

akien-mga Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

stuartcarnie commented Oct 12, 2025

Uh oh!

stuartcarnie commented Oct 13, 2025

Uh oh!

akien-mga commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stuartcarnie commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

akien-mga commented Oct 15, 2025

Uh oh!

stuartcarnie commented Oct 15, 2025

Uh oh!

akien-mga commented Oct 15, 2025

Uh oh!

stuartcarnie commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stuartcarnie commented Oct 15, 2025

Uh oh!

stuartcarnie commented Oct 16, 2025

Uh oh!

akien-mga commented Oct 16, 2025

Uh oh!

stuartcarnie commented Oct 16, 2025

Uh oh!

stuartcarnie commented Oct 16, 2025

Uh oh!

hpvb commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stuartcarnie commented Oct 17, 2025

Uh oh!

stuartcarnie commented Oct 17, 2025

Uh oh!

akien-mga left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

akien-mga commented Oct 13, 2025 •

edited

Loading

stuartcarnie commented Oct 13, 2025 •

edited

Loading

stuartcarnie commented Oct 15, 2025 •

edited

Loading

hpvb commented Oct 17, 2025 •

edited

Loading