Halide’s hard-coded Mach-O minimum OS versions for AoT output look unnecessarily high

[bc-lee]

LC_BUILD_VERSION is a Mach-O load command that records the target platform and a minimum OS version (and tool versions). Tools like Apple’s linker use it to understand what platform an object/library was built for.

Recent versions of Apple’s linker are more strict about missing platform metadata and can warn when object files or static libraries don’t include the relevant “platform load command”, e.g.:

ld: warning: no platform load command found in '...', assuming: iOS-simulator

This warning has been widely observed since Xcode 15’s linker became more pedantic about this metadata.

Halide addressed this in PR #8323 by ensuring the LLVM target triple includes a minimum OS version when emitting Mach-O objects. In that change, Halide special-cased Intel macOS (x86_64) to use macOS 11.0, with a comment explaining it was “one version prior to the oldest version still supported by Apple” at the time (June 2024).

Later, PR #8546 updated these constraints. It sets:

• macOS x86_64 → 12.0
• iOS (device) → 17.0

This change appears in the Halide v21.0.0 release notes.

Issue

These values are hard-coded in Halide, and downstream users don’t have an easy way to choose a different deployment target for AoT outputs.

For reference, Apple’s Xcode support matrix (as of 2026-01-20) shows Xcode 26.2(which is latest) supports deployment targets down to:

• macOS 11
• iOS 15
  (see https://developer.apple.com/support/xcode/ for details)

Given that, requiring macOS 12.0 and especially iOS 17.0 for Halide AoT-generated objects/libraries seems unnecessarily restrictive. I don’t believe Halide’s AoT outputs inherently require such a high minimum OS version in order to function.

Proposal

For now, I’d suggest lowering Halide’s hard-coded minimums to match Xcode’s supported minimum deployment targets:

• macOS 11.0
• iOS 15.0

Longer term, a better solution would be to make the minimum deployment target configurable (e.g., via a CLI flag analogous to -mmacosx-version-min / -miphoneos-version-min, or a Halide Target feature), but as a small/safe step, lowering the constants would help many downstream users.

What do you think?

[alexreinking]

I'm happy to track "latest Xcode" deployment target minimums. Would that obviate the need for an override?

[alexreinking]

Another question: should we use the value of MACOSX_DEPLOYMENT_TARGET as our configuration point? AppleClang respects this per the man page (though note the command line argument has been changed to -mmacos-version-min, no x).

Same for IPHONEOS_DEPLOYMENT_TARGET.

[bc-lee]

Maintaining hard-coded minimums at “latest Xcode-supported minimum deployment targets” (e.g. macOS 11 / iOS 15) would already solve my immediate problem — I don’t personally need an override if those constants stay aligned with Xcode’s minimums.

Regarding using MACOSX_DEPLOYMENT_TARGET / IPHONEOS_DEPLOYMENT_TARGET as a configuration point like clang does (https://github.com/llvm/llvm-project/blob/3aea01b271ae5908e99cb4b12263ca450ab91afc/clang/lib/Driver/ToolChains/Darwin.cpp#L2075): yes, I think it’s a good idea, although I personally prefer command-line options since they are more explicit. I previously added a --macho-minos option to nasm (in Chromium’s fork) to solve the exact same problem:
https://source.chromium.org/chromium/_/chromium/chromium/deps/nasm/+/3dc3d47978ef567966cb21a7b6d617fb688e6029

[alexreinking]

I personally prefer command-line options since they are more explicit.

Yeah, the issue is that the Halide compiler doesn't have a command line (GenGen binaries notwithstanding). So our only available configuration points are the target string (which we could complicate by parsing a number after ios or osx, the latter of which we should really rename to macos) or environment variables.

As there appear to be well-known environment variables in the ecosystem, I think it's better to use them.

[alexreinking]

I just opened #8915 to address the high minimum versions. A later PR can address the override story, pending a bit more ecosystem research (it seems MACOSX_DEPLOYMENT_TARGET is respected as an environment variable, but IPHONEOS_DEPLOYMENT_TARGET is Xcode-specific).