Do the same as when cross compiling; disallow detecting dependencies
outside of the given CMAKE_FIND_ROOT_PATH. Don't export LLVM_DIR
as we no longer need to pass it implicitly that way.
This makes the errors clearer, if LLVM isn't found where expected,
instead of misdetecting it from a different installation of LLVM
in the system.
If lldb-mi would try to find other optional dependencies, they would
no longer be found; this was already the case when cross compiling
though.
As build-llvm now can create a larger variety of build dir names,
enumerating all possible suffixes becomes problematic (especially
as they don't necessarily appear in one canonical order).
Instead, iterate over potential matches. If cross compiling, it
is easy as we can require the directory to contain the expected
suffix. If not cross compiling, we have no explicit suffix to look
for, but we can check that the directory doesn't match common
cross compilation triples.
Passing --instrumented=IR or --instrumented=Frontend builds
instrumented tool binaries. After running them and merging the
output profile files, run build-llvm.sh with
--profile=profile.profdata.
When cross compiling with llvm-mingw, we already implicitly use
clang and lld, but we don't need to specify these options as they
are set implicitly via the llvm-mingw wrappers.
Don't use tools from $PREFIX/bin automatically; this can be
confusing and problematic. If running with $PREFIX/bin in path,
the build at this stage gets reconfigured if rebuilding after
installing clang.
For multistage builds, install into separate toolchain
directories and add the right one to $PATH before invoking
build-llvm.sh. If one really wants to use the tools from $PREFIX
for a new build into the same directory, one has to add that
directory to the path manually.
This is an option I set outside of this script in a number of
build cases where I build with ccache; move this into the script.
In practice it has little effect though; one has to set
CCACHE_BASEDIR anyway in order to be able to share a ccache
between build directories.
If enabling ccache by adding e.g. /usr/lib/ccache to the front of
PATH, without using the COMPILER_LAUNCHER variable, this won't
get enabled.
This allows specifying either a commit or a branch in the same
field, allowing simplifying both the workflow inputs, and
the expressions for passing commit/branch to both
dawidd6/action-download-artifact and actions/checkout.
This new option is available since
https://github.com/dawidd6/action-download-artifact/pull/329.
As the branch field has a default value "master", this default
not only applies when the dialog box for starting the manual
workflow is presented. But even if the prefilled branch field
is cleared, the default value also gets substituted when submitting.
In this case, when the commit and branch fields are mutually
exclusive, we can't easily have a default. Instead change the
uses of the fields, ignoring the branch field if the commit field
is filled.
If the dawidd6/action-download-artifact action would support
specifying either a commit or a branch in the same field, like
actions/checkout does, we wouldn't need this distinction at all;
this request is tracked upstream at
https://github.com/dawidd6/action-download-artifact/issues/242.
This requires setting CMAKE_CXX_COMPILER_TARGET manually; the LLVM
build system infers the wrong architecture when CMake is an
x86_64 binary.
(The wrong inferred architecture doesn't affect building libcxx,
but the wrong architecture gets passed as --target= parameter
when running the tests.)
Since 9c67ae861ccb0312fc680414a8441892d169d14a in llvm-project
(May 9th), these tests should pass on aarch64 too.
Co-authored-by: Jeremy Drake <github@jdrake.com>
Currently, "macos-latest" gets "macos-14", while there also are
"macos-15" runners available. Switch back to the latest variant
in preparation for that being updated at some point.
This reverts 7bd4b284f9.
As the preinstalled CMake on the windows-11-arm runners currently
is an x86_64 build, we need to explicitly specify
CMAKE_SYSTEM_PROCESSOR, and CMAKE_SYSTEM_NAME to make CMake
consider it a cross compilation (otherwise CMAKE_SYSTEM_PROCESSOR
gets overridden by CMAKE_HOST_SYSTEM_PROCESSOR, which gets influenced
by the x86_64 as CMake is running emulated).
We also need to set LLVM_HOST_TRIPLE, as the autodetection of
it relies on CMAKE_HOST_SYSTEM_PROCESSOR. The host triple needs
to be in normalized form with "-windows-gnu", otherwise a couple
dozens of tests fail.
We also include the AArch64 target, to make sure the built compiler
can generate code for the host.
Since 07bc54bf4554398b199f4dc849e5193b98422f23 in llvm-project
(May 5th), these tests should pass on aarch64 too.
Since 3e56f5f41843204b6e612362542b77110f8f8188 in llvm-project,
this should pass for all 4 architectures. (This doesn't pass
in the pinned release version right now.)
This avoids relying on finding these dependencies in $PATH while
running the tests. Some tests may set PATH="" while executing them,
which previously caused those tests to fail in this build setup.
The same is not an issue with MSVC builds with
-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL, because those
DLLs are also available in global system directories (including
DLLs such as msvcp140.dll and vcruntime140.dll).
When removing them, also accept that they are missing to begin
with.
Since 655933070219f2b6f3a457c7e5af7edd4b5291b4 in llvm-project
(Apr 25th), asan only gets built for x86.
This matches what 28851edf164a337c334755ae33fd58f03cffd5a2 in
llvm-project did.
When setting up the built libcxx files for testing, the built
files are installed into a temporary test root, and the install of
them litters the build log with mostly uninteresting output.
This was not converted in 5fe2e05419,
probably because those (automake based) makefiles work fine with
BSD make.
Use $MAKE here anyway, for consistency.
As the releases are built (without a surrounding extra container)
on GitHub Actions these days, we don't need to hold the docker
images back to an old version for the sake of compatibility;
instead, updating to a newer version provides more modern tools
for users of the docker image.
The script release.sh, which earlier was used for building releases,
uses docker for doing clean isolated builds, and thus needs to be
updated with the distro version used in the dockerfiles.
CMake 4.0 removed compatibility with CMake versions below 3.5.
Therefore, it errors out on projects with a
cmake_minimum_required() less than 3.5.
(Since CMake 3.31, it already warns that compatibility with versions
below 3.10 is deprecated.)
By passing CMAKE_POLICY_VERSION_MINIMUM=3.5, we indicate that
we are ok with configuring this project with the policies of
CMake 3.5, even if the project files themselves don't state it.
This flag is only recognized by CMake 4.0; older versions will
only warn that the manually specified variable is unused.
Relevant changes in LLVM 20.1.x compared with LLVM 19.x are:
- Don't warn when doing LTO with mixed Rust/C object files, where
the target triples differ in the vendor field
(<arch>-w64-windows-gnu vs <arch>-pc-windows-gnu)
- Fix including LLVM/MSVC style import libraries in libraries linked
with --whole-archive
- Support for files over 2 GB in the libcxx fstream methods
tellg()/seekg()
- Lots of work on improved ARM64EC and ARM64X support in LLVM and LLD
- New linker flags --dependent-load-flag and --functionpadmin, similar
to the corresponding lld-link/MS link.exe flags
- Improvements in address sanitizer, supporting many more x86
instructions
- Changes to address sanitizer, that (unintentionally) makes it fail
harder than before when used together with msvcrt.dll. Using
address sanitizer with msvcrt.dll is unsupported though.
Since 6127724786d581d2653df7420d1f28709288a107 in llvm-project
(Nov 4 2024), this variable no longer is referenced, and it
probably hasn't been needed for much longer than that.
It's enough to check for the _UCRT define these days, as long
as we are including a header that pulls in the base mingw headers.
Since 8b2ece59fccf0a65257b1ba2fe8d67d7e8a2e8c1 in mingw-w64 (May 6th
2019), the mingw-w64 headers define _UCRT. Since
94a28397eec79e54ce5a8354512f43da88f815d2 (committed on the same date),
the mingw-w64 headers use 0xE00 instead of 0x1400 for UCRT.
This reverts commit 490dfffb32.
This is no longer necessary, as we now can build runtimes using
the latest LLVM 19 versions, that support building sanitizers
for all architectures.
Update to using clang-18 from the host system; version 16 or
newer is required for the implicitly selected config files
(which are used since 866d47cced);
that version changed whether the target triples are normalized
before locating config files.
This allows building runtimes with the current versions of LLVM
19.x, rather than needing to select an older version.
This is one of the packages which aren't needed by the toolchain
build itself, but is provided as a convenience to useres of the image.
Many projects that build standalone x86 assembly can use either
nasm or yasm, but lately most projects prefer nasm (which has
support for newer x86 simd extensions).
In Ubuntu 24.04, this package is no longer available.
However, this package probably never actually was needed anyway,
and was probably only provided as a convenience for users of the
docker image.
This is required for building libffi. With ubuntu-22.04 images,
the libltdl-dev package was available out of the box.
Also explicitly install swig, which we rely on - this also seems
to have been available implicitly.
This fixes building on Ubuntu 24.04 (the one currently used by
the github actions ubuntu-latest tag), by including a fix for texinfo
7.0.
Not bumping to ffmpeg 7.x, as some tests there can be flaky at times.
Martin Storsjö