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).
Martin Storsjö