Xcode 26.4's iPhoneOS SDK advertises arm64e (not arm64) in
libSystem.tbd. After stripping the platform suffix, the arch list
contains arm64e, which doesn't match when CMAKE_OSX_ARCHITECTURES
includes arm64. As a result, arm64 falls through to the simulator
SDK, silently breaking iOS device builds.
Since arm64e is a superset of arm64 (all arm64e devices run arm64
binaries), we now fall back to checking for arm64e when arm64 is
not found in an SDK's architecture list.
Add bare minimum functionality to compile C code and link on Windows.
Explicitly label tests that are expected to work with `CFLAGS=-Ze`.
Leave out documentation for now because this is not usable in general.
Issue: #21536
Inspired-by: Serguei E. Leontiev <leo@sai.msu.ru>
Previously, `CMAKE_<LANG>_LINK_FLAGS` was an undocumented variable used
for linking executables only. Re-spell that variable mirroring the
existing spellings for shared and module libraries, and add policy
CMP0210 to preserve compatibility.
Then, repurpose `CMAKE_<LANG>_LINK_FLAGS` to provide a variable to be
used for per-language link flags for all target types, along with a
per-configuration variant. These are added to the `<LINK_FLAGS>` rule
placeholder in the generators.
Fixes: #21934
Relates: #25620
Co-authored-by: Brad King <brad.king@kitware.com>
In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20) we added a `set()` that is
immediately followed by another `set()` of the same variable. Remove
the former.
Fixes: #27019
In commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16,
v4.2.0-rc1~607^2~3) this flag was added as part of an attempt to support
shared libraries without requiring projects to set much themselves. That
attempt was reverted by commit d361bf365e (Emscripten: Drop hard-coded
-sMAIN_MODULE and -sSIDE_MODULE flags, 2025-09-18, v4.2.0-rc1~146^2).
Also avoid hard-coding `-fPIC`. `POSITION_INDEPENDENT_CODE` is already
enabled for shared library targets. Projects can enable it themselves
where `-fPIC` is needed outside of shared libraries.
Fixes: #27424
Issue: #27240
Since commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16,
v4.2.0-rc1~607^2~3), compilation command-lines for Emscripten place
`-c <SOURCE>` before all the flags. Restore the original order.
Fixes: #27404
Extend commit e78abf94e3 (VS/Android: Use ApplicationTypeRevision 3.0 in
VS2022, 2023-04-21, v3.27.0-rc1~165^2~4) to cover VS 2026 too. This was
missed in commit 3392b371e2 (VS: Add Visual Studio 18 2026 generator,
2025-08-20, v4.2.0-rc1~165^2~1).
Xcode by default targets the SDK's macOS version rather than the host's
macOS version. In commit 7b19531291 (macOS: Do not pass any
SDK/-isysroot to compilers by default, 2024-11-06, v4.0.0-rc1~511^2) we
reverted commit 24aafbde11 (Xcode: Adjust deployment target SDK version
to host version, 2015-10-11, v3.4.0-rc2~6^2), but it is still needed for
Xcode. Restore the behavior so binaries run on the host by default.
Fixes: #27309
We have a few code paths needed only to support builds hosted on
macOS 10.4. Update the conditions to work when cross-compiling
to macOS from another platform.
This backports commit eb8facd396 (macOS: Avoid relying on sw_vers
when cross-compiling from another OS, 2025-04-28, v4.1.0-rc1~260^2)
to CMake 4.0.
Fixes: #26814
Revert commit 2853326e7a (BUG: Only set CMAKE_OSX_DEPLOYMENT_TARGET on
Mac OSX 10.4 or later, 2009-01-27, v2.8.0~1169). AFAIK no one is using
macOS versions older than 10.4 anymore.
This backports commit 476b2a386f (macOS: Remove outdated condition
for CMAKE_OSX_DEPLOYMENT_TARGET, 2025-04-28, v4.1.0-rc1~260^2~1)
to CMake 4.0.
Visual Studio defines this automatically for `.dll` targets.
For consistency, define it when compiling for the MSVC ABI
with other generators. Add policy CMP0203 for compatibility.
Fixes: #27253
These flags are only needed for builds involving shared libraries,
and can cause undesirable behavior when they are not needed.
They also have variants with values like `=2`. For now, just require
projects to add the flags when needed so they have full control.
In the future we may be able to add an abstraction to control them,
and automatically enable them when linking to shared libraries
or creating them.
Fixes: #27232
Issue: #27240
Extend commit 644ad91e6a (Emscripten: Restore support for emsdk
toolchain file and platform module, 2025-09-17) to support using a
third-party `CMAKE_TOOLCHAIN_FILE` that includes the emsdk-provided
toolchain file.
Issue: #27232
Place the flag early on executable link lines so that projects can
override it, e.g., with `-sMAIN_MODULE=2` or `-sMAIN_MODULE=0` via
`target_link_options`.
The `-sSIDE_MODULE` flag already appears early enough on shared library
link lines.
Issue: #27232
Emscripten provides a combined toolchain file and platform module that
predates CMake upstream support. It disables support for shared libs.
Fix commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16) to
avoid linking with `-sMAIN_MODULE` or `-sSIDE_MODULE` flags, meant to
support shared libraries, when using the emsdk toolchain file.
Fixes: #27232
Emscripten provides a combined toolchain file and platform module that
predates CMake upstream support. Since commit 96d9b94a98 (Emscripten:
Add platform modules, 2025-05-16), our `Platform/Emscripten` module is
included instead, suppressing existing behavior for users that set
`CMAKE_TOOLCHAIN_FILE` to the emsdk-provided toolchain file. Restore
the previous behavior by teaching our module to defer to the original
module in that case.
Issue: #27232
LLD automatically resolves newly encountered symbols using object files
previously encountered. Also, the Emscripten compiler driver invokes
the LLD linker with `--whole-archive ... --no-whole-archive` around all
the libraries. Therefore we should not repeat any.
Issue: #27232
Suggested-by: Marc Chevrier <marc.chevrier@gmail.com>
Update commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16)
to account for commit 67639002ad (Ninja,Makefile: Drop now-unused
placeholders from link rule variables, 2025-06-09, v4.1.0-rc1~37^2~1).
With Clang, `CMAKE_C_COMPILER_TARGET` adds a `--target=` flag as part of
the `<CMAKE_C_COMPILER>` placeholder, causing the flag to be passed to
our `ExportImportList` script. Tolerate it.
Fixes: #27167
Clear `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS` since no special
link flags are needed to create a DLL with MSVC toolchains.
Our shared library creation rules never referenced that placeholder,
so this variable was never used until commit 951e4d3f62 (Ninja,Makefile:
Move builtin linker flags to <LINK_FLAGS> placeholder, 2025-06-09,
v4.1.0-rc1~37^2~2) taught the generators to look it up directly.
This was not previously noticed because the `-shared` flag
is ignored unless the `-WX` flag enables an error on it.
Fixes: #27106
Brad King
Ben Boeckel
Trung Nguyen
Tor Arne Vestbø
Colin Cross
Serguei E. Leontiev
Willem Deconinck
Eduard Voronkin
Aditya Vidyadhar Kamath
Nilsen84
Gavin Zhao
Tyler YankeeandBrad King
Eisuke Kawashima
Tristan Daifuku
AJIOB
David Tenty
Eduard Voronkin