Extend xcrun SDK resolution to all Apple platforms for NativeAOT linker#126893
Extend xcrun SDK resolution to all Apple platforms for NativeAOT linker#126893
Conversation
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries |
On macOS 15+, Swift stdlib shims may only exist under the Xcode SDK path and not in /usr/lib/swift. This causes NativeAOT builds to fail intermittently when linking libSystem.Security.Cryptography.Native.Apple.a. Resolve the macOS SDK path via `xcrun --show-sdk-path` and add it as an additional -L linker search path. iOS-like platforms are unaffected since they already pass -isysroot which remaps -L paths automatically. Agent-Logs-Url: https://github.com/dotnet/runtime/sessions/1ea30f49-d15d-45c6-be1d-9572f6f8bf28 Co-authored-by: agocke <515774+agocke@users.noreply.github.com>
| <!-- Resolve macOS SDK path for Swift library lookup. On macOS 15+, Swift stdlib shims | ||
| may only exist under the SDK (e.g. <Xcode SDK>/usr/lib/swift) and not in /usr/lib/swift. | ||
| iOS-like platforms already get this through -isysroot which remaps -L paths. --> | ||
| <Exec Command="xcrun --show-sdk-path" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMsBuild="true" | ||
| Condition="'$(_targetOS)' == 'osx' and '$(_HasDefaultSysRoot)' != 'true'"> | ||
| <Output TaskParameter="ConsoleOutput" PropertyName="_MacOSXSdkPath" /> | ||
| </Exec> |
There was a problem hiding this comment.
Can we just change the condition for the `xcrun --show-sdk-path above to also work for macos instead of only iOS-like platforms?
There was a problem hiding this comment.
@copilot this suggestion seems good, let's make that change
There was a problem hiding this comment.
Done in e858ef0. Extended the existing xcrun conditions from _IsiOSLikePlatform to _IsApplePlatform and added _AppleSdkName=macosx for osx targets. This sets SysRoot for macOS so the existing -isysroot on the linker command handles the SDK path remapping automatically. Error conditions remain iOS-only so macOS builds degrade gracefully if xcrun isn't available.
|
OK, after going back and forth with copilot, the operating theory is that this is a difference in xcode-select and whether or not the machine has been configured for full command line tools, vs full xcode config. I'm not sure that's right, but I think it's plausible. So this fix seems reasonable. |
There was a problem hiding this comment.
Pull request overview
This PR updates the NativeAOT Unix MSBuild targets to improve macOS 15+ linking reliability by adding an additional Swift library search path derived from the Xcode macOS SDK, addressing missing auto-linked Swift shim libraries during linking.
Changes:
- Resolves the macOS SDK path for
osxtargets by invokingxcrun --show-sdk-path(best-effort). - Adds
-L<macOS SDK>/usr/lib/swiftto NativeAOT linker arguments for macOS, while keeping the existing/usr/lib/swiftfallback.
| <!-- Resolve macOS SDK path for Swift library lookup. On macOS 15+, Swift stdlib shims | ||
| may only exist under the SDK (e.g. <Xcode SDK>/usr/lib/swift) and not in /usr/lib/swift. | ||
| iOS-like platforms already get this through -isysroot which remaps -L paths. --> | ||
| <Exec Command="xcrun --show-sdk-path" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMsBuild="true" |
There was a problem hiding this comment.
The new SDK path resolution uses xcrun --show-sdk-path without specifying a macOS SDK, and it hardcodes xcrun instead of using the existing $(Xcrun) indirection. xcrun will honor SDKROOT/developer environment and can return a non-macOS SDK path, and hardcoding bypasses any user override of Xcrun. Consider setting Xcrun for all Apple targets (not just iOS-like) and invoking "$(Xcrun)" --sdk macosx --show-sdk-path here so the resolved path is deterministic for osx builds.
| <Exec Command="xcrun --show-sdk-path" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMsBuild="true" | |
| <Exec Command=""$(Xcrun)" --sdk macosx --show-sdk-path" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMsBuild="true" |
…of separate macOS block Agent-Logs-Url: https://github.com/dotnet/runtime/sessions/1cf65e66-4b7b-409c-bd4c-58c477560e6f Co-authored-by: agocke <515774+agocke@users.noreply.github.com>
Description
NativeAOT builds fail intermittently on macOS-15 arm64 because Swift auto-linked libraries (
swift_Builtin_float,swift_errno, etc.) fromlibSystem.Security.Cryptography.Native.Apple.acannot be found. The linker targets hardcode-L/usr/lib/swift, but on macOS 15+ these shims may only exist under the Xcode SDK path.iOS-like platforms are unaffected because they already resolve the SDK via
xcrun --show-sdk-pathand pass-isysrootwhich makes Apple'sldremap all-Lpaths relative to the sysroot. macOS desktop targets (_targetOS == 'osx') previously didn't participate in this SDK resolution, so the hardcoded/usr/lib/swiftpath was the only search location.Changes:
_AppleSdkNametomacosxfor osx targets, matching how iOS-like platforms already define their SDK namesXcrunproperty initialization,command -vcheck, andxcrun --show-sdk-pathconditions from_IsiOSLikePlatformto_IsApplePlatformso macOS also resolves its SDK path intoSysRoot-isysroot "$(SysRoot)"linker argument (already conditioned on_IsApplePlatform) then automatically remaps-L/usr/lib/swiftto<SDK>/usr/lib/swift_IsiOSLikePlatformso macOS builds degrade gracefully if xcrun is unavailable (e.g., cross-compilation from non-macOS hosts whereSysRootwould be set manually)