Find the macOS SDK when only the Command Line Tools are installed - #2614
Open
iurisilvio wants to merge 1 commit into
Open
Find the macOS SDK when only the Command Line Tools are installed#2614iurisilvio wants to merge 1 commit into
iurisilvio wants to merge 1 commit into
Conversation
chearon
reviewed
Aug 22, 2026
| break candidate; | ||
| } else std.mem.trim( | ||
| u8, | ||
| b.run(&.{ "xcrun", "--show-sdk-path" }), |
Collaborator
There was a problem hiding this comment.
Seems like it would be super simple to only rely on this command rather than checking predefined directories. Does that work for you?
I did a little reading and it doesn't seem like using the latest SDK breaks compatibility with old macOS. Backward compatibility for macOS binaries is specified by a zig target like "x86_64-macos.10.15-none", which is the equivalent of the clang arg "-mmacos-version-min".
Contributor
Author
There was a problem hiding this comment.
Yes, you're right! Thank you! I cleaned up the code, works for me and I agree it is backward compatible.
iurisilvio
force-pushed
the
macos-sdk-command-line-tools
branch
from
August 24, 2026 08:22
6c18a1c to
972fddb
Compare
The SDK path was built as `xcode-select --print-path` plus
`Platforms/MacOSX.platform/Developer/SDKs/`, which only exists inside a full
Xcode. With the Command Line Tools selected the SDKs sit directly under
`SDKs/`, so the link step failed with
warning: unable to open library directory
'/Library/Developer/CommandLineTools/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.sdk/usr/lib'
after compiling everything.
Ask xcrun for the SDK instead, which answers for either layout.
The pinned MacOSX15.sdk was not holding the build to that SDK to begin with:
zig resolves the SDK for the link itself and the paths added here only
supplement it, so a native build recorded `sdk 26.5` with or without the pin.
What a binary runs on comes from the target -- `-Dtarget=aarch64-macos`, which
is what publish.yaml passes, gives `minos 13.0` -- and not from here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
iurisilvio
force-pushed
the
macos-sdk-command-line-tools
branch
from
August 24, 2026 08:25
972fddb to
cc0c9de
Compare
Contributor
Author
|
I don't think the Windows failure is related to this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Building on a Mac without a full Xcode fails at the link step, after compiling every dependency:
Platforms/MacOSX.platform/Developer/SDKs/only exists inside an Xcode installation. With the Command Line Tools selected,xcode-select --print-pathreturns/Library/Developer/CommandLineToolsand the SDKs sit directly underSDKs/.Changes
Ask
xcrun --show-sdk-pathfor the SDK, which answers for either layout. That also retires thexcode-selectcall, which only existed to build the pinned path.The pinned
MacOSX15.sdkwas not holding the build to that SDK to begin with — zig resolves the SDK for the link itself, and the paths added here only supplement it:What a binary runs on comes from the target, not from this block. With the triple
publish.yamlpasses:One real difference: the old
-isystemhad compilation pull headers from the 15 SDK, soFontManagerMacos.ccnow compiles against the newest installed one instead. Atminos 13.0, anything introduced after 13.0 is weak-linked and clang warns if it is called unguarded — nothing the current CoreText usage goes near, but it is the actual behavioral change between the two versions.Verification
macOS 26 arm64, Command Line Tools only (no Xcode), zig 0.16.0:
zig buildsucceeds and the full suite passes (305 tests).