| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
* ensure tapi lookup is applied only for concerned toolchains
* fix typos in tests
Fixes: #25182
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
- The comparison for minimum version for detecting the newer xlinkavr
was encompassing V7.30.5, which uses the old `xlink` without target suffix.
|
|
|
|
|
|
| |
- Added C17 support
- Added C++17 support
- Changed: IAR UBROF Linker (XLINK) suffixed with target architecture (xlinkavr)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Fixes: #24123
|
|
|
|
|
| |
`ld.lld` is an ELF linker, so we should never set `CMAKE_LINKER` to this
when targeting an Apple platform.
|
|\
| |
| |
| |
| |
| |
| | |
fee36b7a78 BinUtils: Restore llvm-ar fallback on Apple platforms
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7077
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
| |
| |
| |
| |
| | |
73d0d4e4b5 BinUtils: Avoid llvm-mt because it is missing 'mt' features we use
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7054
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
| |
| |
| |
| |
| | |
29ea94e17c BinUtils: Avoid llvm-ar on Apple platforms
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7039
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
| |
| |
| |
| |
| | |
48f29b5805 IntelLLVM: Use MSVC linker with MSVC frontend variant
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6719
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\ \
| |/
| |
| |
| |
| |
| | |
5dd981539f BinUtils: Avoid llvm-strip versions older than Clang 11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6655
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
|
|
| |
If `lld` is not available, Clang can still use `ld`.
Fixes: #22500
|
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
| |
Update our Intel linker and archiver rules to use the `<CMAKE_LINKER>`
and `<CMAKE_AR>` placeholders instead of hard-coding the tool names.
|
|
|
|
|
|
| |
Update our OpenWatcom linker and archiver rules to use the
`<CMAKE_LINKER>` and `<CMAKE_AR>` placeholders instead of
hard-coding the tool names.
|
|
|
|
| |
Consistently consider more-specific names before less-specific names.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
f5d3da091b Clang: Look for llvm-lib when using MSVC-like front-end
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Thomas Bernard <thomas@famillebernardgouriou.fr>
Merge-request: !5264
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Fixes: #21137
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|
|
|
| |
Fixes: #19728
|
| |
|
|
|
|
|
|
| |
Objects compiled with -flto can only be linked with the llvm linker.
Before this change, clang-cl only supperted IPO with manual linker
selection.
|
| |
|
|
|
|
|
| |
LLVM 8.0 already ships with alternatives for all
current Binutils. Enable them.
|
|
|
|
|
| |
use the name pattern `_CMAKE_ADDITIONAL_<PROGRAM_NAME>_NAMES`,
and unset those variables at the end of the function
|
|
|
|
|
|
|
| |
This allows cmake to use the ar/ranlib/objdump/ld tools on windows
without mingw installed.
These tools are selected when clang is in GNU command line mode.
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMake commands vs_link_dll and vs_link_exe, performing linking on MSVC,
are responsible for calling resource compiler and manifest tool.
Before this commit, both of these tools were called directly, with the
expectation that they are available in the `PATH`. This has been fixed
by respecting CMake variables `CMAKE_RC_COMPILER` and `CMAKE_MT`
defining paths to these tools.
Fixes: #17804
|
|
|
|
|
| |
We use this in `Modules/Platform/Windows-NVIDIA-CUDA.cmake`, so make
sure it is available.
|