Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#351 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@ChouChiu がすでに取り組んでいます。

2026年10月24日 から。

  • #392 @ChouChiu による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
ios, linux, swift

調査の方向性

Start in Sources/PackLib/Packer.swift around Plan.Product.linkerSettings (lines 245-271), which currently emits only rpath and entry-point flags, and check whether the generated builder package needs a sysroot flag for non-macOS hosts. Read PR #321 first, since it proposes a fix but is not linked to this issue. Done means a Linux build with a Darwin SDK reports the versioned SDK (e.g. 27.x) in the sdk field of LC_BUILD_VERSION, confirmed with the llvm-objdump --macho --private-headers command from the issue.

索引モデルが issue の本文から書いたものです。

説明

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.)

主要言語
Swift
スター
5.5k
フォーク
163
平均マージ
18時間 29分
マージ済み PR(30日)
27

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

xtool-org/xtool のほかの issue

xtool-org/xtool の issue をすべて見る

似ている issue

Swift の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。