Linux builds record the deployment target as the SDK version in LC_BUILD_VERSION (no -isysroot at link time) #351

Binaries built with xtool on a Linux host record the deployment target in the sdk field of LC_BUILD_VERSION, not the actual SDK they were linked against. App Store Connect enforces a minimum SDK for uploads, so an otherwise-valid build can be rejected just because its Mach-O header claims an old SDK.

What happens

With a Darwin SDK from a current Xcode (say 27.x) and an iOS deployment target of 17.0, a binary built with xtool dev build on Linux gets:

Load command N
      cmd LC_BUILD_VERSION
  platform IOS
    minos 17.0
      sdk 17.0   <-- should be 27.x

minos is right; sdk wrongly repeats the deployment target.

Why

xtool's generated builder package passes no sysroot flag to clang at link time. On current main, Plan.Product.linkerSettings (Sources/PackLib/Packer.swift:245-271) only emits -Xlinker -rpath / entry-point flags, and grep -rn "isysroot" Sources/ on main has no hits. The Darwin SDK reaches the linker only via swift-driver's --sysroot, but clang's Darwin driver only reads SDKSettings.json (the only place that records the real SDK version) when it is given -isysroot. Without it, the -platform_version clang hands to the linker carries the deployment target in the SDK slot, and that lands in LC_BUILD_VERSION.

On macOS hosts the Xcode-managed toolchain injects -isysroot itself, so this only shows up on the Linux/WSL path — xtool's headline platform.

Impact

Any iOS binary produced on Linux has a wrong sdk value in LC_BUILD_VERSION. It doesn't affect local device installs, but App Store Connect rejects uploads whose recorded SDK is older than the required minimum — the build gets rejected even though it was actually linked against a current SDK.

Suggested direction

Pass -Xclang-linker -isysroot <SDK> for the app and extension targets of the generated builder package when a Darwin SDK is installed and the host is not macOS, selecting the versioned SDK directory matching the triple (e.g. iPhoneOS27.1.sdk from the installed artifact bundle). The root cause arguably belongs in swift-driver (use -isysroot for Darwin targets), so an upstream report is worth filing too.

I couldn't build on this machine, so the trace above is static; the behavior itself is easy to reproduce on a Linux host with a Darwin SDK:

xtool new Hello && cd Hello && xtool dev build --ipa
llvm-objdump --macho --private-headers xtool/Hello-App.app/Hello-App | grep -A4 LC_BUILD_VERSION

PR #321 proposes a fix along these lines, but I couldn't find an issue tracking the underlying bug, so filing this for visibility. (Searches for isysroot, sysroot, BUILD_VERSION, minimum SDK, App Store Connect found nothing; #117 is the generic "upload builds to App Store" feature request.)