Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
The compiler does not yet support everything needed to integrate well
with the MSVC ABI, in particular for runtime library selection and debug
format selection. Document them in FIXME comments and leave this
support undocumented by CMake for now.
Fixes: #24840
Inspired-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Default use of `llvm-mt` was disabled by commit 73d0d4e4b5 (BinUtils:
Avoid llvm-mt because it is missing 'mt' features we use, 2022-03-08,
v3.23.0-rc3~7^2). However, it can still be specified explicitly by the
user. Due to limitations of LLVM's command line option parser, llvm-mt
does not support arbitrary manifest files following a single switch.
Issue: #23305
Previously we added fallbacks to `llvm-{ar,strip}` on Apple hosts
in case of cross-compiling because the `APPLE` platform variable
was not set w.r.t. the target platform. The platform variable
has been fixed, so remove the fallbacks.
Issue: #23333
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we prefer `llvm-strip` over
`strip` when using Clang. However, `llvm-strip` seems to produce
unusable binaries in cases involving chained fixups. Prefer Apple's
`strip` over `llvm-strip` on `APPLE` platforms.
We still need to consider `llvm-strip` as a fallback as explained for
`llvm-ar` by commit fee36b7a78 (BinUtils: Restore llvm-ar fallback on
Apple platforms, 2022-03-15, v3.23.0-rc4~12^2).
Issue: #24601
Since commit 29ea94e17c (BinUtils: Avoid llvm-ar on Apple platforms,
2022-03-03, v3.21.6~1^2) we do not consider `llvm-ar` at all on Apple
platforms. However, there are existing cross-compiling use cases in
which the toolchain has `llvm-ar` but not `ar`. Prior to the
re-ordering in commit cf82300a63 (BinUtils: Clarify search logic and
make it more consistent, 2021-05-27, v3.21.0-rc1~119^2~2), we preferred
`ar` and then `llvm-ar`. Restore the original order for Apple.
Fixes: #23320
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-mt` over `mt` when using Clang. However, the
`llvm-mt` tool does not yet support all the flags we need in the
implementation of `vs_link_{exe,dll}`. Prefer plain `mt` for now.
Fixes: #23305
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-ar` over `ar` when using Clang. However, on
Apple platforms, `llvm-ar` does not generate a symbol table that the
Apple linker accepts. Fall back to `ar` on Apple platforms.
Fixes: #23269
The Intel compiler (pre-LLVM) expected xilink.exe and had special logic to
set xilink.exe. The newer LLVM-based compiler does not want xilink.exe.
link.exe works better for host code, and is the default, so change
the matching condition such that the old compiler matches (and gets
xilink.exe) and the new compiler gets the default link.exe it expects.
A better solution will be to use the compiler as the linker. A future
change will switch to compiler as linker by default, but that fix needs
more validation.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-strip` over `strip` when using Clang. However,
`llvm-strip` from Clang versions prior to 11 require extra flags to
strip everything. Until our `install(TARGETS)` logic learns to add
those flags, avoid using older versions of `llvm-strip` by default.
Fixes: #22785
Since commit 5b9bfe738c (IAR: Moved search logic to BinUtils.,
2021-07-19, v3.21.1~14^2), we use the `IN_LIST` operator in the
`CMakeFindBinUtils` module. Set policy `CMP0057` to ensure it is
available regardless of the project's policy settings.
Fixes: #22640
Our `find_program` calls specify `HINTS` to look in the toolchain's
directory first, and then in `PATH`. `CMAKE_PREFIX_PATH` may be
specified by the user to help find packages for project dependencies,
but this should not override the binutils.
Fixes: #22512
The search logic for the IAR linker, librarian and related tools is
moved from `Modules/Compiler/IAR-FindBinUtils.cmake` to
`Modules/CMakeFindBinUtils.cmake` by introducing an new elseif block
for the IAR toolchain.
The search logic was refactored to omit repeating itself.
Fixes: #22425
Given the compiler to use, `CMakeFindBinUtils.cmake` automatically
determines a number of tools including linker (CMAKE_LINKER) and archiver
(CMAKE_AR) and stores them in a generated file `CMakeCCompiler.cmake` as
non-CACHE entries. The compiler-specific ARMClang.cmake then tries to
override CMAKE_LINKER and CMAKE_AR as CACHE entries.
Following the introduction of CMP0126, which is set to NEW in the test
for a working compiler, setting a CACHE entry does not replace a normal
entry of the same name anymore, resulting in a failed test due to wrong
linker and archiver.
To fix this, set CMAKE_LINKER and CMAKE_AR for ARMClang directly in
`CMakeFindBinUtils.cmake` as is done for other compilers. Check
for them in `ARMClang.cmake` to safeguard cases when a project explicitly
includes `ARMClang.cmake` prior to compiler determination (which some
projects do to work around other problems in older CMake versions).
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27) we correctly prefer the more-specific name
`llvm-objdump` over `objdump` when using Clang. However, this breaks
`file(GET_RUNTIME_DEPENDENCIES)` with `llvm-objdump` from Clang 8 and
below. Avoid those older versions of `llvm-objdump`.
Since commit 4d786dfcfa (BinUtils: Avoid clobbering a variable named
without a private prefix, 2021-04-06, v3.20.1~4^2) we use variables
named `_tool` and `_name`, but these may still be common enough to
affect project code. Use `_CMAKE_TOOL` and `_CMAKE_TOOL_NAME` instead,
and unset them when finished.
Fixes: #22140
Refactoring in commit b12aec6c8d (BinUtils: prefer bin utils matching
the compiler version extension, 2020-12-11, v3.20.0-rc1~171^2)
accidentally leaked a `TOOL` variable. Name temporary variables with a
private prefix.
Fixes: #22035
Set `CMAKE_SYSTEM_PROGRAM_PATH` in `Platform/Android-Initialize` instead
of `Platform/Android` so it can be used in `CMakeFindBinUtils`.
Also add the names `llvm-strip` and `llvm-ranlib` for the corresponding
tools.
In commit 55196a1440 (MSVC: Use 'lib' instead of 'link /lib' to create
static libraries, 2020-01-10, v3.18.0-rc1~625^2) we changed CMake to use
lib instead of `link /lib` to create static libraries, but it didn't
search for `llvm-lib`. If you have `llvm-lib` but not `lib` (e.g. when
cross-compiling), when `CMakeFindBinutils` is invoked for the `C` and
`CXX` languages, `CMAKE_AR` is not found. When it's subsequently invoked
for the ASM language, `CMAKE_ASM_SIMULATE_ID` and
`CMAKE_ASM_COMPILER_FRONTEND_VARIANT` are not set (because
`CMakeDetermineASMCompiler` doesn't call `CMAKE_DETERMINE_COMPILER_ID`,
which sets those variables), so we go down the non-MSVC conditional and
set `CMAKE_AR` to a GNU-style `ar`, which of course does not understand
lib flags. Explicitly search for `llvm-lib` to avoid this situation.
5ece12b7e4 gitlab-ci: add ISPC to the Fedora CI image
8976817d6d ISPC: Update help documentation to include ISPC
2368f46ba4 ISPC: Support building with the MSVC toolchain
e783bf8aa6 ISPC: Support ISPC header generation byproducts and parallel builds
34cc6acc81 Add ISPC compiler support to CMake
419d70d490 Refactor some swift only logic to be re-used by other languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5065
Since commit c5dd2ca538 (DetermineCompiler: Relax
_CMAKE_TOOLCHAIN_PREFIX detection, 2020-03-25, v3.18.0-rc1~430^2),
`_CMAKE_TOOLCHAIN_PREFIX` may be set even when not cross-compiling.
In this case we may still need to use binutils without any prefix.
Fixes: #21103
`link.exe /lib` is an undocumented flag and it just calls `lib.exe`.
Also `link.exe` doesn't parse the `/lib` option correctly when in a
response file.
Revert commit b2fd479df5 (FindBinUtils: Use the compiler to get the path
to compiler tools, 2019-09-22, v3.16.0-rc1~51^2). The compiler's answer
may incorrectly come from the `PATH`. Another approach will be needed.
Fixes: #19934
Some unset calls were added by commit 079b8e2916 (Clang: prefer lld-link
over link.exe, 2019-07-11, v3.16.0-rc1~161^2~2) but they are unnecessary
since commit 3a82ef78eb (CMakeFindBinUtils: Rename and unset variables
for additional names, 2019-07-23, v3.16.0-rc1~332^2~2).
Suggested-by: Norbert Lange <nolange79@gmail.com>
Arkadiusz Skalski