Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#351 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
ios, linux, swift
Área
build-system, mobile-dev

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Swift
Estrellas
5.5k
Forks
163
Merge medio
19 h 33 min
PR fusionados (30 d)
25

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de xtool-org/xtool

Todos los issues de xtool-org/xtool

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.