When determining the install prefix in LLVMConfig.cmake etc resolve
symlinks in CMAKE_CURRENT_LIST_FILE first. The motivation for this is to
support symlinks like `/usr/lib64/cmake/llvm` to
`/usr/lib64/llvm19/lib/cmake/llvm`. This only works correctly if the
paths are relative to the resolved symlink.
It's worth noting that this *mostly* already works out of the box,
because cmake automatically does the symlink resolution when the library
is found via CMAKE_PREFIX_PATH. It just doesn't happen when it's found
via the default prefix path.
Move `FindLibcCommonUtils` from LLVM's CMake module directory to the
shared top-level CMake directory, as the module is intended to be used
from within the source tree rather than the installed LLVM version. This
fixes standalone offload builds after #131205.
LLD has a bug regarding ordering of static link libraries in the ELF backend, which has been reported as #116669.
CMake 3.31.0 started properly deduplicating static libraries for LLD causing the following linking failure for `libclang-cpp.so` with `-DLLVM_LINK_LLVM_DYLIB=ON`:
```
ld.lld: error: undefined symbol: llvm::omp::getOpenMPClauseName(llvm::omp::Clause)
>>> referenced by OpenMPKinds.cpp
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/OpenMPKinds.cpp.o:(clang::getOpenMPSimpleClauseTypeName(llvm::omp::Clause, unsigned int))
>>> referenced by SemaOpenMP.cpp
>>> tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaOpenMP.cpp.o:(clang::SemaOpenMP::CheckOMPRequiresDecl(clang::SourceLocation, llvm::ArrayRef<clang::OMPClause*>))
>>> referenced by SemaOpenMP.cpp
>>> tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaOpenMP.cpp.o:(clang::SemaOpenMP::CheckOMPRequiresDecl(clang::SourceLocation, llvm::ArrayRef<clang::OMPClause*>))
>>> referenced 166 more times
[tons more]
```
CMake 3.31 also introduced CMP0179, which builds on CMP0156 and makes the deduplication consistent across platforms.
By coincidence this works around the above LLD deficiency and is the fix that CMake 3.31.1 will implement.
However, the fix is to ignore CMP0156 unless CMP0179 is also enabled, i.e. no more deduplication.
So enable CMP0179 to keep the benefits of deduplication from CMP0156 on LLD and fix the build for CMake 3.31.0.
See: #116669
See: https://gitlab.kitware.com/cmake/cmake/-/issues/26447
Fixes: cb90d5b
Some linkers do not require that libraries are repeated on the command
line. The Apple linker emits warnings when duplicate libraries are
specified, resulting in a wall of warnings.
CMP0156 deduplicates libraries on the command line when the linker
doesn't require them.
This patch enables CMP0156 to quiet the warnings when using a version of
CMake that recognizes it (CMake 3.29 and newer).
The runtimes used to support a build mode called the "Standalone build",
which isn't supported anymore (and hasn't been for a few years).
However, various places in the code still contained stuff whose only
purpose was to support that build mode, and some outdated documentation.
This patch cleans that up (although I probably missed some).
- Remove HandleOutOfTreeLLVM.cmake which isn't referenced anymore
- Remove the LLVM_PATH CMake variable which isn't used anymore
- Update some outdated documentation referencing standalone builds
CMP0114 was originally set to old to get rid of warnings. However, this
behavior is now set to new by default with the minimum CMake version
that LLVM requires so does not produce any warnings, and setting it
explicitly to old does produce a warning in newer CMake versions. Due to
these reasons, remove this check for now.
Splitting off from removing the CMP0116 check just in case something
breaks.
Partially fixes#83727.
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the tests. This allows a clang built on a machine with a new linker
to run compiler-rt tests on a machine with an old linker.
rdar://125198603
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
A project that bundles the llvm source code may have their own
PACKAGE_VERSION variable, so only use this to compute the
CLANG_RESOURCE_DIR if CLANG_VERSION_MAJOR is undefined.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D152608
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
These will be replaced by CMake's check_linker_flag once we update
the minimum CMake version 3.20.
Differential Revision: https://reviews.llvm.org/D145716
These will be replaced by CMake's check_linker_flag once we update
the minimum CMake version 3.20.
Differential Revision: https://reviews.llvm.org/D145716
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
Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:
CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
Unknown CMake command "cmake_push_check_state".
Call Stack (most recent call first):
cmake/modules/LLDBConfig.cmake:52 (find_package)
cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
CMakeLists.txt:28 (include)
Gentoo Bug: https://bugs.gentoo.org/880065
Differential Revision: https://reviews.llvm.org/D137555
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
This reverts commit 88d7508dc479210f07abccb17f0194b66264b125.
It's reported to break builds when symlinking other projects inside
the `tools` directory.
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Firstly, we we make an additional GNUInstallDirs-style variable. With
NixOS, for example, this is crucial as we want those to go in
`${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir
of the "regular" libdir, which is installed even when no one needs to do
any development.
Secondly, we make *Config.cmake robust to absolute package install
paths. We for NixOS will in fact be passing them absolute paths to make
the `${dev}` vs `${out}` distinction mentioned above, and the
GNUInstallDirs-style variables are suposed to support absolute paths in
general so it's good practice besides the NixOS use-case.
Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other
install dirs are.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D117973
FindLibEdit uses pkg-config to find the necessary flags, but this may break with cross-compilation,
because the PkgConfig module in CMake doesn't respect the SYSROOT specified in a toolchain file.
Instead of taking the parameters from pkg-config for granted, we check whether our compiler can
actually include and link against the library.
Fixes#55445Fixes#55671
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D126450
Currently, LLVM's LineEditor and LLDB both use libedit, but find them in different (inconsistent) ways.
This causes issues e.g. when you are using a locally installed version of libedit, which will not be used
by clang-query, but by lldb if picked up by FindLibEdit.cmake
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124673
Sometimes, we could be building for a platform where we don't link
compiler-rt, so being able to figure out the right compiler-rt suffix
isn't necessary, but we shouldn't fail the build.
This patch uses CMAKE_OSX_SYSROOT, which should contain the SDK path
that we're building against on Apple platforms, to determine which
platform we are compiling for and set the compiler-rt suffix accordingly.
Differential Revision: https://reviews.llvm.org/D122161
When using COMPILER_RT_USE_BUILTINS_LIBRARY=ON and clang-cl there
where several places where it didn't work as expected.
First -print-libgcc-file-name has to be prefixed with /clang:
Then the regex that matched the builtins library was wrong because
the builtins library is called clang_rt.builtins_<arch>.lib
and the regex only matched libclang_rt.builtins_arch.a
With this commit you can use a runtime build on Windows with this
option enabled.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D120698
We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
