[maccatalyst][coreclr] Fix native build failure on Xcode 26.2

[davidnguyen-tech]

Summary

Replace CMAKE_OSX_DEPLOYMENT_TARGET=17.0 with CMAKE_OSX_DEPLOYMENT_TARGET=14.0 in the maccatalyst cmake args in eng/native/build-commons.sh.

Problem

Building for maccatalyst fails on Xcode 26.2 with:

clang: error: invalid version number in '-mmacosx-version-min=17.0'

The build sets CMAKE_SYSTEM_NAME=Darwin with CMAKE_OSX_SYSROOT=macosx, so CMake interprets CMAKE_OSX_DEPLOYMENT_TARGET=17.0 as a macOS deployment target and emits -mmacosx-version-min=17.0. But 17.0 is a Mac Catalyst version number, not a macOS version. Older clang accepted this silently; Xcode 26.2's clang rejects it as a hard error during CMake's compiler test, before configurecompiler.cmake can apply the correct -target arm64-apple-ios17.0-macabi triple.

Fix

Change CMAKE_OSX_DEPLOYMENT_TARGET from 17.0 (Catalyst version) to 14.0 (the equivalent macOS version). CMake uses this value only for its initial compiler test (-mmacosx-version-min), and 14.0 is a valid macOS version that clang accepts. The effective Catalyst minimum version is enforced separately via the hardcoded -target *-apple-ios17.0-macabi triple in eng/native/configurecompiler.cmake.

Validation

Full clr+clr.runtime+libs+packs build for maccatalyst-arm64 succeeds with this change on Xcode 26.2 / CMake 4.2.0.

[davidnguyen-tech]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Removes an invalid macOS deployment target setting from the Mac Catalyst native CMake configuration to unblock builds on Xcode 26.2, where clang now hard-errors on -mmacosx-version-min=17.0.

Changes:

• Drop -DCMAKE_OSX_DEPLOYMENT_TARGET=17.0 from the maccatalyst CMake args so CMake’s compiler test uses a valid macOS min-version.
• Keep Mac Catalyst targeting driven by the explicit *-apple-ios17.0-macabi target triple applied later by configurecompiler.cmake.

[davidnguyen-tech]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidnguyen-tech]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[kotlarmilos]

Thanks @davidnguyen-tech. Is this failure encountered in the dotnet/dotnet build?

Having CMAKE_OSX_DEPLOYMENT_TARGET explicitly defined avoids unexpected behavior when the OS version changes. Could we set a new default minimum value?

[davidnguyen-tech]

Thanks @davidnguyen-tech. Is this failure encountered in the dotnet/dotnet build?

Having CMAKE_OSX_DEPLOYMENT_TARGET explicitly defined avoids unexpected behavior when the OS version changes. Could we set a new default minimum value?

I haven't tried it in dotnet/dotnet yet - only in dotnet/runtime.

Yes, setting a default minimum value makes sense. Thanks for suggestion.

[davidnguyen-tech]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[akoeplinger]

I wonder if we can just remove CMAKE_OSX_DEPLOYMENT_TARGET, according to the comment in

runtime/eng/native/configurecompiler.cmake

Lines 711 to 715 in 92741be

	# Somewhere between CMake 3.17 and 3.19.4, it became impossible to not pass
	# a value for mmacosx-version-min (blank CMAKE_OSX_DEPLOYMENT_TARGET gets
	# replaced with a default value, and always gets expanded to an OS version.
	# https://gitlab.kitware.com/cmake/cmake/-/issues/20132
	# We need to disable the warning that -target replaces -mmacosx-version-min

it should result in some default value (which gets overridden by the -target)

[davidnguyen-tech]

Yes we can, that was the original solution, but I set a default value explicitly based on this comment:

Having CMAKE_OSX_DEPLOYMENT_TARGET explicitly defined avoids unexpected behavior when the OS version changes.
#124220 (comment)

But if CMAKE_OSX_DEPLOYMENT_TARGET doesn't really get consumed, we should be safe.

On the other hand, setting an explicit default is a more defensive choice.

What do you think?