Every rung of the macOS SDK resolver is a read: a failing xcode-select, an
SDKROOT that names no installed SDK, or a bare directory posing as one falls
to the next rung, ending in the xcrun selection the builders used before.
An unusable SDKROOT is reported on stderr and ignored, which matches how
`xcrun --sdk macosx` treated it. SDKSettings.plist proves a directory is an
SDK, since xcrun accepts any existing path.
Native coverage builds both universal helpers with a stale SDKROOT, a plain
directory as SDKROOT, and an older installed SDK when the host has one.
Resolve SDKROOT through xcrun before passing a sysroot to clang. Exercise both real universal helper builds with default, absolute and named SDK selection, and retain resolver precedence and fallback coverage.
`xcrun --sdk macosx` resolves to the highest-versioned SDK installed, not the
one the active toolchain ships with. On a host whose SDKs outrank its Command
Line Tools (e.g. MacOSX27.0.sdk alongside CLT 26.6), the .tbd stubs declare
architectures the linker cannot parse, so every native helper fails to link
and the desktop build dies at the `desktop` stage.
The comment added for #113708 assumed `--sdk macosx` names the toolchain's own
default SDK; it does not. Resolve the MacOSX.sdk symlink under the active
developer dir instead, which is the SDK that toolchain actually pairs with, and
honour SDKROOT so CI and packagers can pin their own.
The two native tests that compile fixtures inline hit the same wall, so they
take the shared helper too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
