Bump up to LLVM 15 #1691
Merged
Bump up to LLVM 15 #1691
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for your contribution! Please make sure to follow our Commit Convention. |
|
The failure on windows is surprising to me. Here a couple of things I already looked into: https://releases.llvm.org/15.0.0/projects/libcxx/docs/ReleaseNotes.html mentions:
which is further discussed at https://reviews.llvm.org/D109459 and https://reviews.llvm.org/D114786. I had tried to build lean4 stage 1 with C++11, but could not get it working. There are also a small number of reports that point to wrong include directories (mostly for apple builds). I am not sure what is breaking here. |
bollu
force-pushed
the
oct-04-llvm-15
branch
2 times, most recently
from
08149a9
to
e8a32b0
Compare
bollu
commented
Oct 14, 2022
| @@ -29,8 +29,8 @@ find stage1 -type f -exec strip --strip-unneeded '{}' \; 2> /dev/null | |||
| # lean.h dependencies | |||
| $CP llvm/lib/clang/*/include/{std*,__std*,limits}.h stage1/include/clang | |||
| # ELF dependencies, must be put there for `--sysroot` | |||
| $CP $GLIBC/lib/crt* llvm/lib/ | |||
| $CP $GLIBC/lib/crt* stage1/lib/ | |||
| $CP $GLIBC/lib/*crt* llvm/lib/ | |||
There was a problem hiding this comment.
Ah, that's what you meant. Thanks!
bollu
commented
Oct 14, 2022
| @@ -29,8 +29,8 @@ find stage1 -type f -exec strip --strip-unneeded '{}' \; 2> /dev/null | |||
| # lean.h dependencies | |||
| $CP llvm/lib/clang/*/include/{std*,__std*,limits}.h stage1/include/clang | |||
| # ELF dependencies, must be put there for `--sysroot` | |||
| $CP $GLIBC/lib/crt* llvm/lib/ | |||
| $CP $GLIBC/lib/crt* stage1/lib/ | |||
| $CP $GLIBC/lib/*crt* llvm/lib/ | |||
There was a problem hiding this comment.
Ah, that's what you meant by adding them from $GLIBC. Thanks!
auto-merge was automatically disabled
October 14, 2022 09:29
Head branch was pushed to by a user without write access
Co-authored-by Sebastian Ullrich<sebasti@nullri.ch>
This replaces the hardcoded 'llvm/lib/x86_64-unknown-linux-gnu/lib' with 'llvm/lib/*/lib'. This is necessary to be able to handle both x86_64 and aarch64.
This is for me to check my mental model; AFAIU, we want to set the host compiler to have this configured correctly. By luck, on the other builds, it used to be the case that 'llvm-host' is symlinked to 'llvm'.
Just like the 'lib/' data is now in 'lib/<target-triple>', it seems like a similar change has happened to 'include'. Copy the file '__config_site' outside of 'include/<target-triple>/c++/v1/__config_site' to live in 'include/c++/v1/__config_site'.
set '-resource-dir $PWD/stage1/lib/clang/14.0.0'
to '-resource-dir $PWD/stage1/lib/clang/15.0.1'.
TIL what '-resource-dir' is. It holds compiler
specific includes (eg. `stdbool`) and libraries
(eg. constructor and destructor things from 'libcrt{begin/end}'.
We use the `host` compiler (which is going to be `x86_64`), while linking against the `target`runtime (which is `aarch64`) to produce the Lean toolchain. The `sysroot` option sets the path for the `host` compiler to pickup the runtimes for the `target`? So in our case, the `sysroot` should point to the `aarch64` runtime (ie, the `target` runtime).
We only care about 'llvm' (target), not 'llvm-host', as the runtime we link against is the target `aarch64` runtime, not the host `x86_64` runtime.
Note that the path bugs exist for both the host and the target compiler. Setup the paths for the host compiler runtime as well, thereby preventing errors like: -- Check for working CXX compiler: /home/runner/work/lean4/lean4/build/llvm-host/bin/clang++ - broken The C++ compiler "/home/runner/work/lean4/lean4/build/llvm-host/bin/clang++" is not able to compile a simple test program. It fails with the following output: /home/runner/work/lean4/lean4/build/llvm-host/bin/clang++ -o CMakeFiles/cmTC_a289a.dir/testCXXCompiler.cxx.o -c /home/runner/work/lean4/lean4/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx /home/runner/work/lean4/lean4/build/llvm-host/bin/clang++: error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory make[1]: *** [CMakeFiles/cmTC_a289a.dir/build.make:78: CMakeFiles/cmTC_a289a.dir/testCXXCompiler.cxx.o] Error 127 make[1]: Leaving directory '/home/runner/work/lean4/lean4/build/CMakeFiles/CMakeTmp' make: *** [Makefile:127: cmTC_a289a/fast] Error 2
Replicate the <__config_site> header fix from the target compiler on the host compiler.
I am unsure why this suddenly breaks.
I am unsure what flags are passed to the linker. Dump 'Scrt1.o' in the obvious location of the 'sysroot/lib', and check if this succeeds. This is for me to understand why the linker fails.
I hope I didn't clean up too much...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Let us refactor the patch that adds LLVM support to Lean4 into another component: We first bump up LLVM to LLVM 15, and then add the bindings.
We see that the windows build breaks at this stage in itself. Help debugging this would be great, @Kha !