* It is possible to setup llvm-project builds without going through
`llvm/CMakeList.txt` so the fatal error handling should be smarter.
* Disable option on Apple style lldb-linux builds.
Building the Apple way turns off plugin support, meaning we don't need
to export unloadable symbols from all executables. While deadstripping
effects aren't expected to change, enabling this across all tools
prevents the creation of export tries. This saves us ~3.5 MB in just the
universal build of `clang`.
Since LLVM supports `-ffat-lto-objects` we should enable this as an
option in the LLVM build. FatLTO should improve the time it takes to
build tests for LTO enabled builds of the compiler by not linking w/ the
bitcode portion of the object files, which should speed up build times
for LTO builds without disabling optimizations.
ld: warning: ignoring duplicate libraries:
This triggers quite frequently in llvm's build because CMake's library
depends mechanism doesn't de-duplicate libraries on the link line.
Duplication is necessary for ELF platforms, but means something subtly
different on Darwin platforms, hence the warning. Since we don't have
much control over that from CMake, just disable the warning wholesale
whenever the linker is detected to support it.
Summary:
Turns out that we need this for the header install directory. I didn't
notice because I had old values cached. Revert for now until I think of
a better way to suppress the error.
Summary:
I've begun treating GPU runtimes builds as cross-compiling with the LLVM
infrastructure. However, we include a lot of random stuff that the GPU
build isn't prepared to handle. This currently emits a warning, and
while it's not striclty necessary, is annoying. This patch suppresses it
by not including the standard GNU install directory resources when used
from the GPU.
1. Replace the obsolete `llvm_add_unittests()` CMake function with an
explicit check for `TARGET llvm_gtest`. This is more consistent with the
rest of the code, and it makes it possible to avoid checking out
`third-party` tree.
2. Add `LLDUnitTests` test dependency to standalone builds. It is
defined unconditionally, and actually necessary to ensure that unit
tests will be built.
Currently `add_lit_target` sets the `USES_TERMINAL` CMake option. When
using Ninja, this forces all lit testsuite targets into the
single-threaded `console` pool.
This PR adds a new option `LLVM_PARALLEL_LIT` which drops the
`USES_TERMINAL` flag, allowing Ninja to run them in parallel.
The default setting (`LLVM_PARALLEL_LIT=OFF`) retains the existing
behavior of serial testsuite execution.
This symlink was added in 91a384621e5b762d9c173ffd247cfeadd5f436a2 to
maintain backwards compatibility, but it needs to point to
libLLVM.so.$MAJOR.$MINOR rather than libLLVM.so. This works better for
distros that ship libLLVM.so and libLLVM.so.$MAJOR.$MINOR in separate
packages and also prevents mistakes like
libLLVM-19.so -> libLLVM.so -> libLLVM.so.18.1
Fixes#82647
We need to do this now that we are bumping the minor release number when
we create the release branch.
This also results in a slight change to the library names for LLVM. The
main library now has a more convential library name:
'libLLVM.so.$major.$minor'. The old library name: libLLVM-$major.so is
now a symlink that points to the new library. However, the symlink is
not present in the build directory. It is only present in the install
directory.
The library name was changed because it helped to keep the CMake changes
more simple.
Fixes#76273
illumos has an older version of the Solaris linker that does not
support the GNU version script compat nor version scripts and does
not support -Bsymbolic-functions. Treat illumos linker separately.
The libclang/CMakeLists part lifted from NetBSD's pkgsrc.
Build tested on Solaris 11.4 and OpenIndiana 2023.10.
/usr/bin/ld --version
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3260
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1790 (illumos)
This adds dlltool to the list of tools which don't get excluded from
installation when LLVM_INSTALL_TOOLCHAIN_ONLY is set.
The most important effect here is that this tool will now be included in
the official Windows release.
While llvm-lib reuses the dlltool machinary internally and has many of
the same capabilities, it does not expose the functionality controller
by the '-k' flag, which is currently the only way to create import
libraries for i386 with stdcall symbols from a module definition alone.
We avoid changing llvm-lib tool, since it is designed to emulate LIB.EXE
from MSVC toolchain, and as this functionality is not supported there,
we would have had to introduce an LLVM extension flag in order to
support it.
See https://reviews.llvm.org/D36548 for reference on rationale for
dlltool '-k' flag.
`CMAKE_{C/CXX}_FLAGS` affects all targets in LLVM. This can
be undesirable in situations, like the case of enabling thinLTO,
where `-flto` is added to every source file. In reality, we only
care about optimizing a select few of binaries, such as clang or lld,
that dominate the compilation pipeline. Auxiliary binaries in a
distribution and not on the critical path can be kept non-optimized.
This PR adds support of per-target linker flags, which can solve the
thinLTO problem by negating the effects of LTO via targeted linker
flags on the targets. The example of negating thinLTO
above can be done by doing the following:
```
set(LLVM_llvm-dwarfdump_LINKER_FLAGS "-Wl,--lto-O0" CACHE STRING "Custom linker flags to llvm-dwarfdump")
set(LLVM_lldb_LINKER_FLAGS "-Wl,--lto-O0" CACHE STRING "Custom linker flags to lldb")
```
There's other applications where this could be used (e.g. avoid
optimizing host tools for build speed improvement etc.).
I've generalized this so that users can apply their desired flags to
targets that are generated by `llvm_add_library` or
`add_llvm_executable`.
Internally, our toolchain builds were on average 1.4x faster when
selectively choosing the binaries that we want optimized.
This cmake rule is used by external clients, who may or may not have
the LLVM_LIBRARY_OUTPUT_INTDIR variable set.
If it is not set, then we pass `-Wl,-rpath-link,` to the compiler. It
turns out that gcc and clang interpret this differently.
* gcc passes `-rpath-link ""` to the linker, which is what we want.
* clang passes `-rpath-link` to the linker. This is not what we want,
because then the linker gobbles the next command-line argument,
whatever it happens to be, and uses it as the -rpath-link target.
Fix this by passing -rpath-link only if we actually have a path we want.
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
Running lit tests on Windows can fail because its use of
`os.path.realpath` expands substitute drives, which are used to keep
paths short and avoid hitting MAX_PATH limitations.
Changes lit logic to:
Use `os.path.abspath` on Windows, where `MAX_PATH` is a concern that we
can work around using substitute drives, which `os.path.realpath` would
resolve.
Use `os.path.realpath` on Unix, where the current directory always has
symlinks resolved, so it is impossible to preserve symlinks in the
presence of relative paths, and so we must make sure that all code paths
use real paths.
Also updates clang's `FileManager::getCanonicalName` and `ExtractAPI`
code to avoid resolving substitute drives (i.e. resolving to a path
under a different root).
How tested: built with `-DLLVM_ENABLE_PROJECTS=clang` and built `check-all` on both Windows
Differential Revision: https://reviews.llvm.org/D154130
Reviewed By: @benlangmuir
Patch by Tristan Labelle <tristan@thebrowser.company>!
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 f55fd19b6b565827af5fbf504952dcc35b8b7360.
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
This reverts commit aa495214b39d475bab24b468de7a7c676ce9e366.
As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch
allows for using LLD-as-a-lib. It also lets clients link only the drivers that
they want (see unit tests).
This also adds the unit test infra as in the other LLVM projects. Among the
test coverage, I've added the original issue from @krzysz00, see:
https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction
Important note: this doesn't allow (yet) linking in parallel. This will come a
bit later hopefully, in subsequent patches, for COFF at least.
Differential revision: https://reviews.llvm.org/D119049
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
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
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
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 21c008d5a5b. That prior attempt was reverted in 959dbd1761c, 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
When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937 / 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 d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937. 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
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
This patch provides initial support of building Clang runtimes for
Windows when using Fuchsia Clang toolchains under Linux.
Differential Revision: https://reviews.llvm.org/D141738
If we don't use the index otherwise, if(IN_LIST) is more readable and
doesn't clutter the local scope with index variables.
This was pointed out by @beanz in D96670.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D142405
This avoids having to specify the location of all individual tools.
In current builds, one may want to specify LLVM_TABLEGEN, CLANG_TABLEGEN,
LLDB_TABLEGEN, LLVM_CONFIG_PATH, CLANG_PSEUDO_GEN and
CLANG_TIDY_CONFUSABLE_CHARS_GEN; specifying just the base directory
containing all of them is much more convenient.
Factorize the code for setting up use of a tool that is used during
the build (which either is newly built in the same build, or
built in a separate nested cmake build - when cross compiling or
when e.g. optimized tablegen is requested - or used from an existing
prebuilt binary).
Differential Revision: https://reviews.llvm.org/D131052
D139623 replaces CMAKE_CFG_INTDIR
with '.' for multi-config builds. However, this change has
not been reflected in mlir, flang, polly, lld, and clang.
The patch updates the path to LLVMConfig.cmake for those
projects.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D141538
Using CMAKE_CFG_INTDIR in paths that are used in configure_file,
resulted in a folder that is literally called '${CONFIGURATION}'
for the multi-config ninja build.
I think this is a regression from a while ago. Fix this by replacing
CMAKE_CFG_INTDIR with '.'. We can only create one of the
LLVMConfig.cmake files as the consuming CMake project can only import a
single file. This creates LLVMConfig.cmake and others in the place where
they were previously and where they are for a single-config build.
Differential Revision: https://reviews.llvm.org/D139623
* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
libatomic may be required only sometimes.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136280
Using a Python script instead of the various shell commands means that
it is now possible to cross compile LLVM for Linux on Windows.
Differential Revision: https://reviews.llvm.org/D136092
On Windows we don't create symlinks for the binaries (clang++, clang-cl)
since the support requires special setup (group policy settings and
you need to know exactly our distribution story). But if you know
about these things and have a controlled environment there is a lot
of storage to be saved, so let's add a manual opt-in for using symlinks
on Windows with LLVM_FORCE_CREATE_SYMLINKS=ON.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D135578
This is another attempt at https://reviews.llvm.org/D110489.
When build IREE we run into cases where we don't have / need
LLVM_VERSION_* etc set. Compilation fails if it isn't an integer.
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D135650
