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
The `-lld` linker flag was added from the previous command-line script
that have all values in `CMAKE_DL_LIBS` prepended with `-l`.
On AIX, the `dlopen()` is otherwise in C library (default). But it seems
that also `libld` library was once needed on some versions to have
dynamic loading working.
Sync `CMAKE_DL_LIBS` value style with all other current usages.
d592558b8b cmLocalGenerator: Drop no-op link flag placeholder infrastructure
67639002ad Ninja,Makefile: Drop now-unused placeholders from link rule variables
951e4d3f62 Ninja,Makefile: Move builtin linker flags to <LINK_FLAGS> placeholder
6b618c6079 cmLocalGenerator: Clarify MODULE link flags placeholder population
c52a654aa1 cmLocalGenerator: Improve formatting of rule placeholder variable list
37cf9941ed UseEcos: Add missing placeholder in rules to link executables
fa61be5bc4 Embarcadero,OpenWatcom: Clear unused flags for creating shared libraries
124e40947c CMakeCommonLanguageInclude: Do not unset MODULE library flags when empty
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10869
Previously we used separate placeholders for builtin linker flags:
* CMAKE_<LANG>_LINK_FLAGS for EXECUTABLEs
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS for SHARED libraries
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS for MODULE libraries
These are now always replaced by the empty string, so drop them
from our rule variables.
ea6b29a367 NVHPC: Add support for 25.07 no-pie option
8ef90ffc52 NVHPC: Add support for COMPILE_OPTIONS_VISIBILITY
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10867
Clear `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS` since no special
link flags are needed to create a DLL with these toolchains.
Our shared library creation rules do not reference the placeholder,
so this variable was never used. However, we may soon teach the
generators to look it up directly.
This was done by mistake in commit d090159318 (ENH: add support for the
ADSP toolchains for Blackfin, Shark and TigerShark DSPs, patch from
Raphael Cotty, 2007-07-12, v2.6.0~1446), and preserved in the
generalization by commit e9eabb0dcd (ADSP: Configure compiler in
compiler module, 2022-03-24, v3.24.0-rc1~331^2~1). Fix both places.
The `CMAKE_{EXE,SHARED,MODULE,STATIC}_LINKER_FLAGS` variables are
not language-specific, so multiple languages' toolchains may disagree
about if/how to pass the flag through a compiler driver to the linker.
Furthermore, carrying the flag in public-facing variables allows projects
or users to change it even though it is required. Add policy CMP0197
to remove the flag from the public-facing variables and generate it
automatically instead:
* For command-line generators, add the `-machine:` flag to the
linker and archiver rule variables.
* For Visual Studio generators, we do not need to explicitly add the
link `-machine:` flag. MSBuild automatically adds it, and the new
behavior actually removes a duplicate we generated previously.
Issue: #21934
With IntelLLVM on Windows, we link using the compiler driver.
With MSVC on Windows, we invoke the linker directly. If we
use both in a single build tree, for separate languages,
the value of `CMAKE_LINK_DEF_FILE_FLAG` conflicts. Add a
per-language `CMAKE_<LANG>_LINK_DEF_FILE_FLAG` variable to
avoid the conflict. Preserve the language-agnostic variable
for compatibility with projects that reference it.
Fixes: #26005
bf1bb62e74 macOS: Restore support for LLVM/Clang without explicit CMAKE_OSX_SYSROOT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10734
In commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to compilers
by default, 2024-11-06, v4.0.0-rc1~511^2) we broke support for using
upstream LLVM/Clang to build for macOS because the compiler has no
default sysroot. Handle empty `CMAKE_OSX_SYSROOT` with LLVM/Clang by
falling back to the macOS SDK reported by `xcrun --show-sdk-path` .
Fixes: #26863
