Ubuntu 20.04 comes with CMake 3.16, so there's no need to install
a custom version of CMake for now (for LLVM 16.x; LLVM 17 will have
the requirement raised to CMake 3.20 though).
Also drop the workaround for git issues in the old version in
Ubuntu 18.04.
The latest releases that are built on GitHub Actions without
docker are based on Ubuntu 20.04 anyway, so there's less demand
for building this with an older version for the sake of
compatibility of the built binaries. For users using the built
docker image as such, having it based on a newer base distribution
is beneficial.
Older macOS versions (macOS 12.2 at least) don't support this
option, while newer macOS versions do support it (macOS 12.6).
The solution is based on https://stackoverflow.com/a/1116890/3115956,
but simplified for this usecase.
These tests should now all pass on both architectures; the
check-asan tests for the static CRT are skipped automatically,
the failures in check-interception have been fixed by compiling
the tests with the --large-address-aware flag, and the
check-asan-dynamic tests on i686 have been fixed - all by
Alvin Wong.
Currently, there's no practical difference if the spelling of this
triple is inconsistent, but if we'd enable e.g. the per-target
runtime directories, the exact spelling does make a difference.
For consistency, pass CMAKE_C_COMPILER_TARGET with the exact right
spelling everywhere.
This reverts commit 056cb22fb5.
The fix for avoiding needing to set CMAKE_*_COMPILER_WORKS,
which means setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
when intiailizing the CMake project setup, was only possible to
apply on compiler-rt/lib/builtins, not other similar projects
like libunwind/libcxxabi/libcxx - so it's expected to keep needing
to set the CMAKE_*_COMPILER_WORKS flags.
Therefore it's also possible that the code in compiler-rt/lib/builtins
could be reverted, as it does have some other minor inconveniences
(it causes some other feature detections to fail, even if they're
harmless within the builtins).
Thus keep setting CMAKE_*_COMPILER_WORKS everywhere consistently.
A couple relevant changes since 16.0.0:
- Fix compilation for ARM (failures in generating SEH unwind info)
for very specific cases
- Link the ASAN DLL before other libs and objects, to make sure it gets
initialized as early as possible
- Allow double backslashes in the PATH in ASAN
- Allow llvm-rc to look for a clang executable named "clang-16", if the
other alternatives aren't available
- Improve the performance of buffered raw_ostream within LLVM
The fewer dynamic library dependencies we have, the easier it is
to run the binaries on other linux distributions than the one it
was built on.
In the docker based releases, these libraries haven't been installed
and thus haven't been used so far.
The docker based releases haven't linked against zlib though, but
keep linking against that, since that should have a quite stable
ABI and not cause much binary compatibility issues.
This should make the produced artifact more widely compatible.
Releases built with release.sh with the dockerfile are currently
based on Ubuntu 18.04 though, and are more shielded from potential
extra libraries that are found during the build.
For non scheduled builds, those env variables are just left empty.
This is much neater than using the "versions" file, and uses much
fewer lines of code.
We still probably want to bundle a file labelling what versions
it contains in the built packages though; give that file a
.txt suffix.
Since e56fb975e9, strip-llvm.sh
has been called as part of build-all.sh.
This avoid stripping out files that have been installed into the
share directory by later stages in build-all.sh. (strip-llvm.sh
currently flat out removes the share directory.)
Keep removing the same items installed by LLVM as before (although
that could be revisited too).
This avoids removing unintended files if running strip-llvm after
the installation of other components.
These test suites now pass in the latest git main.
This target isn't run automatically anywhere, but in case the
target is enabled to run the tests, include the libcxxabi and libunwind
test suites too.
These no longer fail; they were fixed in ffmpeg in commit
76b33704b628248d77ed61cbef9ecd9430a4b6c5 in July 2022; we currently
test a pinned 6.0 release, where this fix is included.
This reduces the differences if using a proper release tarball
instead of an artifact from an earlier step (if testing parts of
the workflow by modifying it).
This was added in 050b4ef701, but this
option was never supported to be passed on to build-llvm.sh from
here.
Additionally, this option was removed entirely from build-llvm.sh
in bd190c04c3.
Normally our releases are cross-built from Linux, but we also
support building the toolchain in MSYS2. Enable the custom defaults
when building the toolchain in MSYS2 too.
Configuring the mingw-w64-crt build takes a really long time on MSYS2;
the generating Makefile phase takes easily 4-5 minutes, when the rest
of configure runs in a matter of seconds. By passing
--disable-dependency-tracking, the whole configure for mingw-w64-crt
takes 11-14 seconds where it previously took many mnutes.
This comes with the drawback that these build directories aren't
suitable for incremental development (unless manual care is taken
to rebuild all necessary files), but these builds are mostly done
for non-interactive building.
Thanks to Jeremy Drake for realizing this optimization opportunity,
and LIU Hao for making me aware of it.
Notable changes for mingw users are:
- Support demangling C++ symbols on i386 in LLVM backtraces
- Don't report fatal errors when the output pipe is closed on Windows
- Ignore file access times on Windows when comparing whether files are
equivalent
Notable changes:
- Support for _FORTIFY_SOURCE=3
- Fortification of [v]s[n]printf for UCRT
- Add the __gets_chk function, for fortification of the (highly
deprecated) gets function
- Fixed the inconsistent signature of the wcstok function on UCRT
in string.h
- Allow opting out from SEH based setjmp/longjmp by defining
__USE_MINGW_SETJMP_NON_SEH before including setjmp.h
And as usual, lots of other minor updates.
This allows the wrappers to invoke the right tool with the right
options, even when the wrapper was invoked with an obfuscated
short form file name.
This happens e.g. when CMake/Ninja invokes the tools from a path
that contains spaces.
While $HOST-clang is more specific for the use in llvm-mingw,
using the form $HOST-gcc would allow using the same script in
GCC based environments too.
Keep this disabled by default (since it takes a fair amount of time
and has good test coverage upstream), but including it in disabled
form so that it's easy to enable temporarily for testing occasionally.
Libcxx does test the mingw configuration in their own CI (with an older
pinned release of the compiler), so this is mostly redundant, and
primarily relevant for testing that the very latest compiler (and
python setup) works for the tests.
It is available on all architectures by default now. Keep the
HAVE_OPENMP conditional within the test makefile to allow custom
testing without having it available.
Since a356782426f5bf54a00570e1f925345e5fda7b2e in llvm-project,
OpenMP can be built for mingw/aarch64, since
fb947c358661b3bd3d5e1fa776ec74cc0f308854 it should work correctly
in all currently tested cases, and since
97958c9bb83cec44b6ce13e732b53de0171a5d43 it can be built for
mingw/armv7.
Curl (or wget) isn't required for fetching libssp any longer,
so don't require it while running build-all.sh.
(It's still required by build-cross-tools.sh, for build-make.sh
though.)
Since using the ssp routines from mingw-w64 instead of those from
GCC's libssp, these messages are included in the piped output of
the process, so we can check for the right messages.
As mingw-w64 now provides these routines, we no longer need to build
the original library from GCC.
As building with -fstack-protector-strong still links with -lssp
(and -lssp_nonshared), we still need to provide libraries with these
names, but they can be empty dummy libraries.
Notable changes:
- Support for CFGuard
- SSP routines are bundled as part of libmingwex, rendering the separate
libssp from GCC unnecessary
Plus lots and lots of various other minor fixes and improvements.
Notable changes are:
- Emit -exclude-symbols: directives for hidden symbol visibility (supported
by LLD 15 and binutils ld 2.40). This allows reducing the number of
exported symbols in e.g. libLLVM-*.dll.
- Support for CFGuard on mingw, thanks to Alvin Wong!
- LLD now picks up libraries named <name>.lib when linking with -l<name>,
even if -static was specified
- Fixed SEH unwind info on AArch64 if using the AArch64 feature
PAC (Pointer Authentication Code) - previously, unwinding would fail if
running on a system that actually does use the feature. (The consistency
of AArch64 SEH unwind info was also improved for other cases.)
- Fixed stack alignment on AArch64, for stack frames large enough to
require stack probing
- Fixed llvm-objcopy corrupting some cases of object files with empty sections
- Improvements to LLDB, where it now uses the regular symbol list of DLLs
(including non-exported symbols)
- OpenMP now can be built and works on armv7 and aarch64 (in mingw
configurations)
Notable for simplifying how to cross compile LLVM itself:
- The preexisting build machine tools can be specified with one single option
LLVM_NATIVE_TOOL_DIR instead of passing a number of variables like
LLVM_TABLEGEN, CLANG_TABLEGEN etc.
Since the switch to building in C++17 mode in llvm 16, lldb-mi is
incompatible, until lldb-mi itself switches to building with C++17 too.
A fix has been suggested upstream in
https://github.com/lldb-tools/lldb-mi/pull/102, but there hasn't
been any action on it so far.
Use the TOOLEXT variable in run-tests.sh in the same way as in the
Makefile. The Makefile sets this variable automatically if invoked
by mingw32-make, but if running run-tests.sh in WSL with native
Windows compilers, then we need to set TOOLEXT manually when calling
run-tests.sh.
Allow skipping the cfguard failure tests when run in such a
configuration, since Linux make in WSL can't easily run cmd.exe
like in MSYS2.
This option was mostly relevant for making it possible to share
ccache between builds in different directories, due to specific
logic in CMake's Ninja generator, which used relative paths for
sources as long as they were below the main source directory
(llvm-project/llvm). This option wasn't usable on Windows.
Since CMake 3.21.0, this option no longer worked for the intended
purpose - that version of CMake changed the Ninja generator to
always use absolute paths to sources, for consistency with other
generators and to simplify things. (See commit
c564a3e3fff52ef811291c5ba8fb07a5a1b47f97 in CMake's git history.)
It is still possible to achieve ccache sharing across build
directories anyway, by setting the ccache option CCACHE_BASEDIR,
which makes ccache rewrite absolute paths to relative ones within
that tree, and by setting the LLVM CMake option
LLVM_USE_RELATIVE_PATHS_IN_FILES=ON, which adds -ffile-prefix-map
options to the compiler, to remap source paths as they are exposed
in the generated code.
(Strictly speaking, LLVM_USE_RELATIVE_PATHS_IN_FILES is only needed
if debug info is enabled. On its own, without CCACHE_BASEDIR, that
option produces compiler output that is identical across build
directories - but the absolute paths end up in the preprocessor output
in source file/line comments, which makes ccache fail to reuse the cache.)
This part of the tests does pass on glibc on x86_64 and on MSVC,
but fails on macOS (for some functions) and on glibc on aarch64
(for one function).
This is a somewhat overly pedantic test, but is useful for checking
the NAN preservation behaviour when modifying implementations.
Also print the sign bit explicitly - not all printf implementations
distinguish between NAN and -NAN when printed.
Martin Storsjö