LLVM_ENABLE_RUNTIMES=flang-rt for UnifiedTreeBuilder builders #387
Conversation
Meinersbur
requested review from
gkistanova,
luporl,
DavidSpickett and
ceseo
Meinersbur
changed the title
Yes, both stage1 and stage2. |
|
After a buildbot master restart flang-aarch64-libcxx (only) stopped working. The error message indicates an ABI issue. Maybe using the wrong headers or linking the wrong library? The issue should be with |
|
@antmox FYI for flang-aarch64-libcxx. I would start by double checking whether the flang-rt tests get built with the host compiler, or the clang that was just built, and what stdlib that/those default to. Also note that this bot does not build libcxx, it uses the host compiler's pre-built version of it. What could be happening is that the host compiler builds the llvm libraries with libcxx, then the just built clang does not. So the flang-rt test is then trying to combine libstdc++ and libc++. I'm not sure we want this bot to be building libcxx as well, but just as an experiment, you could also trying adding that to ENABLE_RUNTIMES and getting the just built clang to use that. Another option may be to tell the just built clang where the host's libcxx is. |
If that is the case, what should the correct solution be? Tell clang to also use libc++ for the runtimes build? |
|
Possible fix: llvm/llvm-project#134990 |
The buidbot [flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is currently failing with an ABI issue. The suspected reason is that LLVMSupport.a is built using libc++, but the unittests are using the default C++ standard library, libstdc++ in this case. This predefined `llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`, which finds the libc++-built LLVMSupport. To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake such that everything that links to LLVM libraries use the same standard library. In this case discussed in llvm/llvm-zorg#387 it was the flang-rt unittests, but other runtimes with GTest unittests should have the same issue (e.g. offload), and any external project that uses `find_package(LLVM)`.
…tion (#134990) The buidbot [flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is currently failing with an ABI issue. The suspected reason is that LLVMSupport.a is built using libc++, but the unittests are using the default C++ standard library, libstdc++ in this case. This predefined `llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`, which finds the libc++-built LLVMSupport. To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake such that everything that links to LLVM libraries use the same standard library. In this case discussed in llvm/llvm-zorg#387 it was the flang-rt unittests, but other runtimes with GTest unittests should have the same issue (e.g. offload), and any external project that uses `find_package(LLVM)`.
…134990) The buidbot [flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is currently failing with an ABI issue. The suspected reason is that LLVMSupport.a is built using libc++, but the unittests are using the default C++ standard library, libstdc++ in this case. This predefined `llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`, which finds the libc++-built LLVMSupport. To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake such that everything that links to LLVM libraries use the same standard library. In this case discussed in llvm/llvm-zorg#387 it was the flang-rt unittests, but other runtimes with GTest unittests should have the same issue (e.g. offload), and any external project that uses `find_package(LLVM)`.
Add
depends_on_projects=['flang-rt']andchecks=['check-flang-rt']to Linaro's builders that are based on UnifiedTreeBuilder. This prepares the removal of the "projects" build of the flang runtime in llvm/llvm-project#124126.Split off from #333
Affected builders:
Affected workers:
I could locally confirm that
flang-aarch64-dylibworks on a x86_64 host (since I don't have an aarch machine other than a Raspberry Pi readily available)