Since 23c665371a98c7a16765d12bf2db19b0626b7181 in llvm-project
(Nov 2, 2022), compiler-rt uses CMake's find_package() for
finding potentially installed LLVM files, instead of using
llvm-config.
If the surrounding distribution does have an unrelated install
of LLVM packages, compiler-rt's CMake files would find this, and
add include directories from it into the include paths used
when building compiler-rt.
The ORC runtimes include libc++ headers, and those error out
on these unexpected include topologies (when libc++'s cstddef
includes stddef.h and expects to get libc++'s stddef.h, but ends
up getting a different stddef.h included). (Without this,
it wouldn't have been noticed that the build ends up using a
mismatched sysroot's headers.)
This fixes building in msys2 in the clang64 environment, where
the base toolchain packages end up including LLVM packages,
including LLVMConfig.cmake.
This fixes the same issue as
3b96433cdf did, for the new form of
compiler-rt cmake files.
When rebuilding in an already built directory, cmake does use
the cache file, containing what variables were set to previously.
When changing build configuration (building with a different prefix,
or changing build configurations) this can often result in failed
cmake runs.
Wipe the cache (and the rest of the cmake temp files) by default.
This makes sure that the full cmake configuration is run each time
when running the build scripts, just like it does the first time.
(This doesn't remove the build artifacts; if nothing of significance
has changed, ninja would still reuse old built files.)
By setting the env variable NO_RECONF, this behaviour can be skipped,
rerunning cmake without wiping the cache inbetween. (For cases where
the user knows that the configuration hasn't changed since the last
build, this can speed up the cmake execution time a bit.)
We normally don't install all tools (including llvm-config), or we might
have stripped them out, but the system distro might have installed a copy
of llvm-config (for a different unrelated installation of llvm).
Some compiler-rt runtimes (such as xray and orc) use this for finding
the main llvm headers.
When building compiler-rt, we really don't want it to pick up any random
version of llvm headers found on the system, but keep using the matching
headers from the monorepo instead.
Adding the include directory of a system provided set of llvm headers
is especially fatal if that directory isn't a subdirectory containing
only llvm headers, but contains other system headers too.
In particular, on msys2, the include directory (pointed at by "llvm-config
--includedir", and also set by including LLVMConfig.cmake which is
pointed at by "llvm-config --cmakedir") is the main system include
directory. Including this can also get headers for a system install
of libc++ headers (for the clang64 msys2 distro) - and using libc++
headers with a second set of libc++ headers in the include path is
fatal (due to include_next not finding the plain C header but finding
a second libc++ header).
Just try to make sure that we don't pick up any unintended headers.
This command isn't a standard tool; different distributions have
different implementations, and e.g. Fedora doesn't ship it by
default.
Settle on using "command -v $tool >/dev/null" for tests about whether
a tool is available. (We could also use "hash $tool 2>/dev/null" as we
already had in build-all.sh, but settling on using "command -v"
everywhere, for consistency and simplicity.)
This reverts parts of commit e35ef3b7d7.
This is now handled better upstream, since
7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021).
Since 8368e4d54c459fe173d76277f17c632478e91add in llvm-project (pushed
on March 11 2021), the lib/builtins CMakeLists.txt sets
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, which makes the
compiler tests pass before the toolchain is fully functional, by not
doing linking tests.
This still requires manually moving the dll files to the arch specific
runtime directory.
This requires building a version of llvm past
8e11bede3a6ac11ebcc05c82fac39899feaf9534 (March 18th 2021)
This is needed since 8bd2722f65cfd7883ed9769f7bad3ff50e4c6905
(and 8e11bede3a6ac11ebcc05c82fac39899feaf9534) in llvm-project
(past the 12.x release branch), which will allow us to get rid of the
whole arch renaming part (once we can assume we're building a version
newer than that).
On windows, we rename clang.exe to clang-$MAJOR.exe, and later
install clang.exe as a wrapper for the default architecture. But
if only building certain architectures, and the host architecture
isn't one of them, we shouldn't install any unprefixed clang.exe at
all.
For build-mingw-w64.sh to succeed when installing to such a path,
the mingw-w64 version has to be updated to the latest git master.
build-mingw-w64-libraries.sh still fails in this case, as libtool
fails to properly quote $LD in a test for whether the linker is GNU ld.
This updates compiler-rt, libunwind, libcxxabi and libcxx to a newer
version, matching the compiler.
This will be the official, canonical repo in the future.
For the non-dev Dockerfile build, this means that all the llvm based
subprojects need to be built in one RUN to avoid storing the llvm
checkout in the docker layers.
For compiler-rt and libunwind, this makes them build successfully even
if llvm-config and the llvm cmake files aren't available.
For libcxxabi, this brings in support for using SEH exceptions.
For libcxx, this removes a few build time warnings.
Martin Storsjö