With the new behaviour, the /MD or similar options aren't added to
e.g. CMAKE_CXX_FLAGS_RELEASE, but are added separately by CMake.
They can be changed by the cmake variable
CMAKE_MSVC_RUNTIME_LIBRARY or with the target property
MSVC_RUNTIME_LIBRARY.
LLVM has had its own custom CMake flags, e.g. LLVM_USE_CRT_RELEASE,
which affects which CRT is used for release mode builds. Deprecate
these and direct users to use CMAKE_MSVC_RUNTIME_LIBRARY directly
instead (and do a best effort attempt at setting CMAKE_MSVC_RUNTIME_LIBRARY
based on the existing LLVM_USE_CRT_ flags). This only handles the
simple cases, it doesn't handle multi-config generators with
different LLVM_USE_CRT_* variables for different configs though,
but that's probably fine - we should move over to the new upstream
CMake mechanism anyway, and push users towards that.
Change code in compiler-rt, that previously tried to override the
CRT choice to /MT, to set CMAKE_MSVC_RUNTIME_LIBRARY instead of
meddling in the old variables.
This resolves the policy issue in
https://github.com/llvm/llvm-project/issues/63286, and should
handle the issues that were observed originally when the
minimum CMake version was bumped, in
https://github.com/llvm/llvm-project/issues/62719 and
https://github.com/llvm/llvm-project/issues/62739.
Differential Revision: https://reviews.llvm.org/D155233
Add an option to specify additional linker flags for unit tests only.
For example, this allows using something like
-DLLVM_UNITTEST_LINK_FLAGS="-Wl,-plugin-opt=O0" if you're doing LTO
builds, or -DLLVM_UNITTEST_LINK_FLAGS="-fno-lto" if you're using
fat LTO objects.
The build system already does this itself if the LLVM_ENABLE_LTO
flag is used, but this does not cover all possible LTO configurations.
Differential Revision: https://reviews.llvm.org/D154212
This reverts commit f55fd19b6b.
As noted on the original thread, other uses of LLVM_LIBRARY_OUTPUT_INTDIR are optional. Will make a separate patch that makes this use optional as well.
It looks like MLIR is using the more modern CMAKE_LIBRARY_OUTPUT_DIRECTORY, but AddLLVM still uses this older LLVM specific alias.
In the specific case I was running into, the empty variable was causing `-Wl,-rpath-link,` on the command line, causing the following argument to be swallowed. This was maddening, because the following argument was the .o file containing `main` and I was getting `main` undefined errors when it was clearly there. This is egregious enough that I chose to guard it.
Differential Revision: https://reviews.llvm.org/D153373
Testing libc++ with CMake 3.27.0-rc1 fails. It seems some of the modules
used in CMake are not included.
The error before this change was
```
CMake Error at <mono-repo>/llvm/cmake/modules/HandleLLVMOptions.cmake:821 (CHECK_C_SOURCE_COMPILES):
Unknown CMake command "CHECK_C_SOURCE_COMPILES".
Call Stack (most recent call first):
CMakeLists.txt:156 (include)
```
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D152619
Currently both ASAN and UBSAN are supported on Windows but only ASAN is enabled in LLVM build system. This patch enables the option to build LLVM with UBSAN on windows.
Tested with clang-cl released in LLVM16.
Submitting on behalf of @dwang.
Reviewed by: andrewng, pgousseau
Differential Revision: https://reviews.llvm.org/D151511
Building clang/llvm as a debug build results in TOC overflow even when
using large code model on AIX. This review updates the
llvm/cmake/modules/HandleLLVMOptions.cmake file to use large glink code
in addition to building as a large code model.
Differential Revision: https://reviews.llvm.org/D151733
This patch adds in CMake option LLVM_ENABLE_LLVM_LIBC which when set to
true automatically builds LLVM libc in overlay mode and links all
generated executables against the libc overlay. This is intended to
somewhat mirror the LLVM_ENABLE_LIBCXX flag.
Differential Revision: https://reviews.llvm.org/D151013
In CMake, "TARGET" is a special keyword. But it's also an LLVM component, which
means downstreams may request "target" or "TARGET" from CMake. Quote such input
so "TARGET" is interpreted as a string rather than a keyword.
This is a followup to 75a0502fe0 (D150884).
Fixes Meson's test suite and an issue which manifested identically to #61436
but appears to have been a slightly different problem.
Bug: https://github.com/mesonbuild/meson/issues/11642
Bug: https://github.com/llvm/llvm-project/issues/61436
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D152121
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.
Differential Revision: https://reviews.llvm.org/D151595
Fixes "dependent projects fail to build with cmake 3.25 and llvm 16-rc4".
When building [latest `iovisor/bcc`](1ea0390725), `cmake` complains about a change in the behavior of operator `IN_LIST`:
```console
CMake Warning (dev) at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake
--help-policy CMP0057" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
IN_LIST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
src/cc/CMakeLists.txt:132 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
if given arguments:
"engine" "IN_LIST" "link_components"
Unknown arguments specified
Call Stack (most recent call first):
cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
src/cc/CMakeLists.txt:132 (include)
```
This patch addresses this issue by setting the aforementioned policy in `LLVM-Config.cmake`.
Reviewed By: mgorny, thesamesam
Differential Revision: https://reviews.llvm.org/D150884
Closes: https://github.com/llvm/llvm-project/issues/61436
As for now, 'extract_symbols.py' can use several tools to extract
symbols from object files and libraries and to guess if the target is
32-bit Windows. The tools are being found via PATH, so in most cases,
they are just system tools. This approach has a number of limitations,
in particular:
* System tools may not be able to handle the target format in case of
cross-platform builds,
* They cannot read symbols from LLVM bitcode files, so the staged LTO
build with plugins is not supported,
* The auto-selected tools may be suboptimal (see D113557),
* Support for multiple tools for a single task increases the complexity
of the script code.
The patch proposes using LLVM's own tools to solve these issues.
Specifically, 'llvm-readobj' detects the target platform, and 'llvm-nm'
reads symbols from all supported formats, including bitcode files. The
tools can be built in Release mode for the host platform or overridden
using CMake settings 'LLVM_READOBJ' and 'LLVM_NM' respectively. The
implementation also supports using precompiled tools via
'LLVM_NATIVE_TOOL_DIR'.
Differential Revision: https://reviews.llvm.org/D149119
- It doesn't work if `ALL_FILES` has `$<TARGET_OBJECTS>` with Makefile generator.
- It was a micro-optimization in the ancient age. (introduced in rGe6bc093b42ff)
`llvm-min-tblgen` is capable of building `llvm/include/llvm`;
- `-gen-attrs`
- `-gen-directive-*`
- `-gen-intrinsics-*`
- `-gen-riscv-target-def`
`llvm-min-tblgen` is built and used only when `llvm-tblgen` is built in-tree.
This is not installed.
`llvm-tblgen` is built with complete set and may be installed.
`check-llvm` uses not `llvm-min-tblgen` but `llvm-tblgen`.
`LLVM_TABLEGEN_PROJECT` overrides the definition of `tablegen(project)`.
`LLVM_HEADERS` is used as the overridden prefix for LLVM header generators.
If `EXPORT` is not specified in `add_tablegen`, its tablegen is treated as internal.
Let `llvm-tblgen` depend on `intrinsics_gen`
Depends on D149072
Differential Revision: https://reviews.llvm.org/D146352
Since `llvm-min-tblgen` has been introduced, `llvm-min-tblgen-host`
would make more sense than `LLVM_HEADERS-tablegen-host`.
Depends on D146352
Differential Revision: https://reviews.llvm.org/D149343
To prevent race in `NATIVE`, let each action depend on preceding action.
At the moment, this is restricted only for "Visual Studio".
For example,
- `llvm-tblgen-host` depends on the target's `llvm-tblgen`.
- `clang-tblgen-host` depends on the target's `clang-tblgen` and `llvm-tblgen-host`.
This is rework for D54153.
`build_native_tool` has been introduced since D60024.
Differential Revision: https://reviews.llvm.org/D149072
When using compiler caching program like ccache, there is no point to
use them on external projects or multi-stage clang builds. As these
builds uses fresh from source code toolchain and will pollute the build
cache. If a compiler launcher is still required, a user can explicity
define `CMAKE_C_COMPILER_LAUNCHER` and `CMAKE_CXX_COMPILER_LAUNCHER` in
`CLANG_BOOTSTRAP_PASSTHROUGH` and `LLVM_EXTERNAL_PROJECT_PASSTHROUGH`
flags to enable compiler launcher in these builds.
Differential Revision: https://reviews.llvm.org/D144603
After building and installing LLVM with LibEdit as a dependency, it is
necessary to find it again when LLVM is consumed by another CMake
project, otherwise CMake will report an error about a missing target.
Note that the FindLibEdit.cmake file is in the "LLVM Common CMake
Utils" directory, outside of the LLVM sub-project source directory, so
the installed LLVMConfig.cmake relies on the user having installed the
LLVM common CMake modules or make available their own Find module.
Also note that the controlling HAVE_LIBEDIT CMake variable in
LLVMConfig.cmake.in has a different naming convention compared to
other similar variables like 'LLVM_ENABLE_TERMINFO'. Refactoring this
name would involve touching additional files and should be a follow-up
commit.
Patch By: ekilmer
Differential Revision: https://reviews.llvm.org/D147153
Recent commit 8f833f88ab modified the installation rpath and did not set `BUILD_WITH_INSTALL_RPATH` correctly on AIX, which led to installation failures on AIX. This patch sets `BUILD_WITH_INSTALL_RPATH` on AIX to fix the installation failures.
Reviewed By: buttaface, daltenty
Differential Revision: https://reviews.llvm.org/D148866
If any LLVM subprojects are built separately, the LLVM build directory
LLVM_LIBRARY_DIR is added to both the build and install runpaths in
llvm_setup_rpath(), which is incorrect when installed. Separate the
build and install runpaths on ELF platforms and finally remove the
incorrect call to this function for compiler-rt, as previously attempted
in 21c008d5a5. That prior attempt was reverted in 959dbd1761, where it
was said to break the build on macOS and Windows, so I made sure to keep
those platforms the same.
Two examples of incorrect runpaths that are currently added, one from
the latest LLVM 16 toolchain for linux x86_64:
> readelf -d clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.*so | ag "File:|runpath"
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.dyndd.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan_aliases.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.memprof.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.scudo_standalone.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.tsan.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_minimal.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_standalone.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
Another is in the Swift toolchain, which builds lldb separately:
> readelf -d swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/{bin/lldb*,lib/liblldb.so}|ag "File:|runpath"
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-argdumper
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-server
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/lib/liblldb.so
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib:/home/build-user/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux:$ORIGIN/../lib/swift/linux]
This patch should fix this problem of absolute paths from the build host
leaking out into the toolchain's runpaths.
Differential revision: https://reviews.llvm.org/D146918
V2: Fix cmake error when -DLLVM_APPEND_VC_REV=OFF
Clang may be built in an environment where Git is not available. In our case,
Clang is part of a larger monorepo which is not Git-based, and
GenerateVersionFromVCS was not able to get source info.
Provide options to pass in repo and revision info from cmake.
```
cmake \
-DCLANG_VC_REPOSITORY=abc://repo.url.com \
-DCLANG_VC_REVISION=abcd1234 \
...
```
This would allow us to prepare the source info beforehand and pass it to the
clang binary.
Differential Revision: https://reviews.llvm.org/D148262
Clang may be built in an environment where Git is not available. In our case,
Clang is part of a larger monorepo which is not Git-based, and
GenerateVersionFromVCS was not able to get source info.
Provide options to pass in repo and revision info from cmake.
```
cmake \
-DCLANG_VC_REPOSITORY=abc://repo.url.com \
-DCLANG_VC_REVISION=abcd1234 \
...
```
This would allow us to prepare the source info beforehand and pass it to the
clang binary.
Differential Revision: https://reviews.llvm.org/D148262
When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067d1 / D131052, it consisted
of refactoring a couple cases of manual logic for tools in
clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include
and mlir/tools/mlir-linalg-ods-gen. The former two had the same
consistent behaviour while the latter was slightly different, so
the refactoring would end up slightly adjusting one or the other.
The difference was that the clang-tools-extra tools respected the
external variable for setting the tool name, regardless of the
LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool
only checked its external variable if LLVM_USE_HOST_TOOLS was set.
LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever
cross compiling, so this shouldn't have been an issue.
In https://github.com/llvm/llvm-project/issues/60784, it seems like
some users do cross compile LLVM, without CMake knowing about it
(without CMAKE_CROSSCOMPILING being set). In these cases, their
build broke, as the variables for pointing to external host tools
no longer were being respected.
The fact that CMAKE_CROSSCOMPILING wasn't set stems from a
non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed
to be set by the user (and if it was, it gets overridden), but one
has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling,
even if the target OS is the same as the current host.
Skip the checks for LLVM_USE_HOST_TOOLS and always respect the
variables for pointing to external tools (both the old tool specific
variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This
makes the logic within setup_host_tool more exactly match the
logic for the clang-tools-extra tools from before the refactoring
in d3da9067d1. This makes the behaviour
consistent with that of the tablegen executables, which also respect
the externally set variables regardless of LLVM_USE_HOST_TOOLS.
This fixes
https://github.com/llvm/llvm-project/issues/60784.
Differential Revision: https://reviews.llvm.org/D146666
When the runtime dir path includes whitespace (ex. when it's installed
under "Program Files" on Windows), the lack of quotes causes the linker
to interpret the path as one or more arguments. None of these path
fragments exist, so the link fails.
Differential Revision: https://reviews.llvm.org/D145827
The change to potentially use symlinks on Windows was added in
https://reviews.llvm.org/D99170.
LLVM_USE_SYMLINKS was added more recently in
https://reviews.llvm.org/D135578 and allows specifying at configure time
whether or not symlinks should be created. The benefit of using this
option is it allows building the package on a symlink-capable Windows
machine with symlinks disabled so that the resulting package can be used
on a Windows machine that doesn't support symlinks.
Differential Revision: https://reviews.llvm.org/D145443
In D61448 the cmake option `LLVM_ENABLE_UNWIND_TABLES` was added.
Despite the name suggesting that the option enables unwind tables, that
patch only uses it to disable them. That makes a difference for
architectures where unwind tables aren't enabled by default. The lack of
unwind tables impacts backtraces and the current handling of the option
doesn't allow enabling them. This patch makes an ON value of
`LLVM_ENABLE_UNWIND_TABLES` actually enable unwind tables.
Differential Revision: https://reviews.llvm.org/D144178
These have the same purposes but two different implementations.
llvm_check_compiler_linker_flag uses CMAKE_REQUIRED_FLAGS which affects
flags used both for compilation and linking which is problematic because
some flags may be link-only and trigger unused argument warning when set
during compilation. llvm_check_linker_flag does not have this issue so
we chose it as the prevailaing implementation.
Differential Revision: https://reviews.llvm.org/D143052
The last non-partial-specified target can collect and check source files.
Case A:
llvm_add_library(foo PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(bar PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(baz ...)
baz checks source files in foo, bar, and baz.
Case B:
llvm_add_library(hoge PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(fuga PARTIAL_SOURCES_INTENDED ...)
llvm_add_library(piyo PARTIAL_SOURCES_INTENDED ...)
llvm_check_source_file_list() # Explicitly checks sources in hoge, fuga, and piyo.
Differential Revision: https://reviews.llvm.org/D142256
Follow-up to https://reviews.llvm.org/D142279 for also enabling `libc++` assertions.
This is particularly useful to recover the assertion checks we had with `llvm::Optional`, before moving to `std::optional`.
Differential Revision: https://reviews.llvm.org/D143612
