flang-aarch64-libcxx bot fails to build after flang-rt was added to the build #135381
Comments
DavidSpickett
added
build-problem
flang
|
I'll be at Euro LLVM so I'm handing this off to a colleague to finish up. Notes for them:
|
|
Thanks for detailed information @DavidSpickett. I was able to reproduce this issue as well, also reaching the conclusion that the problem is mixing stuff built with libc++ with things built with libstdc++. Below I expand a bit more about the cause.
But Analyzing the possible solutions listed above, it seems to me that building the runtime with the host compiler instead of stage 1 compiler is the best one. It's relatively simple, doesn't require many changes, and, as the only runtime that flang-aarch64-libcxx builts is flang-rt, that doesn't have a strong dependency on the version of the C++ compiler and libraries used, it shouldn't be a problem. I will prepare a PR with this change. |
After flang-rt, flang-aarch64-libcxx builder started to fail. Before it, llvm libraries, flang and its runtime were built with the host compiler, but now flang runtime is built with the stage 1 clang. The problem is that the C++ library of these compilers may be incompatible. The linked issue has more details. To avoid this issue, build flang-rt with the host compiler. Fixes llvm/llvm-project#135381
Since flang-rt builds were added to the flang-aarch64-libcxx bot it has been failing with:
The theory is that this is because the host compiler includes libc++ and uses that, but the stage 1 compiler does not. So it's mixing libc++ stuff built by the host compiler with libstdc++ things it has built as part of the runtimes.
#134990 aims to fix this by passing on the LLVM_ENABLE_LIBCXX setting to the runtimes build.
The theory is sound but the bot still failed:
This makes sense given that libcxx is not in LLVM_ENABLE_RUNTIMES, and the stage 1 compiler has no way to know the other host compiler exists in this particular bot's setup. Which is...
So what can we do to fix this?
I think the PR itself is fine, but the bot needs to be updated to work with it.
We need to:
Some routes we could take...
Pass the include and library paths to the stage 1 compiler
Note that:
This works but we would have to hardcode those paths, or put stable symlinks in our docker image and point to those. Which is not ideal as it's one more step to reproduce outside of the container for what is, in theory, a pretty simple build.
Build the runtime with the host compiler instead of stage 1 compiler
We have to build clang to build flang, but we don't have to use the just built clang:
This is basically a standalone build of flang-rt (where you point cmake at flang-rt itself, not llvm) but with more steps. It does work but I'm not sure we're supposed to be doing it this way.
With the way our container is setup, "cc" will be clang and "cxx" clang++. So I'd be fine putting those into llvm-zorg as those names are stable.
Change the builder type and build flang-rt standalone using host compiler
Unified tree builder doesn't seem like it would accept an extra step easily, but flang-aarch64-out-of-tree uses out of tree builder which might. We end up with a bot that is unusual in 2 ways (out of tree and libc++) not one, but it's easier to fit into llvm-zorg.
Or we look at making it an annotated builder where there's total freedom. It's a bit much for a theoretically simple change though.
Add libcxx to runtimes (which does not work)
This one does not work, at least for our goals.
This does give stage 1 clang a libcxx to use but the tests end up compiling against a newer libcxx than they would find when trying to run:
You can fix that with LD_LIBRARY_PATH, but doing that in a bot config is a maintanence problem.
Even if we could get the tests to run this way, we now have tests using 1 version of libcxx, and flang using another. If we actually find a real bug, that's one more dimension to deal with.
So I do not think we should pursue this.
Recommendation
I think we either:
The text was updated successfully, but these errors were encountered: