Remember LLVM_ENABLE_LIBCXX setting in installed configuration #134990
Conversation
Meinersbur
requested review from
DavidSpickett,
kiranchandramohan,
ceseo,
luporl,
antmox,
mgorny,
nikic,
jh7370 and
JDevlieghere
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/10/builds/3180 Here is the relevant piece of the build log for the reference |
|
Unfortunately still not working for flang: https://lab.llvm.org/buildbot/#/builders/89/builds/20320 Various headers are not found, kinda like the failure reported above but more of them: I can test things locally if needed. |
|
If you need help from my end for the failing AMDGPU buildbot, let me know. If this is not an easy fix, can we revert in the meantime? |
|
It is a different error, previous was a linking error (libc++ symbol not found in libstdc++). Now it does not find the libc++ headers. Same with lab.llvm.org/buildbot#/builders/10/builds/3180. If the bootstrapping compiler (clang 19) found them, and they are installed in /usr, shouldn't stage1 clang find them as well? It did so when I tested locally (libcxx via Ubuntu package). |
|
Hmm.. I just looked at the CMake config we use on that failing bot. I don't think we have libcxx installed on the machine and we build with GCC. The CMake command does |
|
@jplehr When libc++ is not installed, why does it use LLVM_ENABLE_LIBCXX=ON? The builder's configure output includes: |
|
I copied the flags we use downstream, not sure why they are the way they are TBH. Will look more into that. On a separate note though, would these flags be doing anything during the |
Would be great because I do not know why stage1-clang does not find the libc++ headers |
|
In our case, the libcxx is not system installed, it's part of the llvm release package we use. So stage 1 clang has no way of knowing where that is unless we tell it. Or enable libcxx in stage 1, but that feels like we're then going to mix 2 versions of libcxx. I'll figure that out. |
|
I've found the settings to get stage 1 clang to use the host compiler's libcxx: Note that you have to set LLVM_RUNTIMES_TARGETS, or the pass through of options doesn't work, or at least, didn't seem to. Needs some changes to be something I'm comfortable putting in a buildbot config, but at least I know it can work. |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/146/builds/2681 Here is the relevant piece of the build log for the reference |
|
I'm not going to be able to work on this due to travel, so I've written up what I know in #135381 and will get a colleague to pick it up. Maybe some of those notes will be useful for the other bots. I have moved our bot to staging (https://lab.llvm.org/staging/#/builders/46), so if you do find fixes for the other bots and want to reland this, go ahead. |
…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)`.
llvm#134990)" This reverts commit 785e7f0. It did not solve the problem with flang-aarch64-libcxx and caused another failure with openmp-offload-amdgpu-runtime-2.
The buidbot flang-aarch64-libcxx 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_gtesttarget uses the LLVMSupport fromfind_package(LLVM), which finds the libc++-built LLVMSupport.To fix, store the
LLVM_ENABLE_LIBCXXsetting 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 usesfind_package(LLVM). This patch fixed the problem for me locally.llvm_gtestdefined here:llvm-project/third-party/unittest/CMakeLists.txt
Line 51 in 74f69c4
Used by flang-rt unittests here:
llvm-project/flang-rt/unittests/CMakeLists.txt
Line 20 in 74f69c4
Used by offload here:
llvm-project/offload/CMakeLists.txt
Line 391 in 74f69c4
Use by libc here (but I don't see where it is added):
llvm-project/libc/benchmarks/CMakeLists.txt
Line 42 in 74f69c4