Fix flang-aarch64-libcxx builder

[luporl]

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

[luporl]

Marked as draft because the changes were only tested in isolation:

• Built and tested flang/flang-rt with the modified flags.
• Called getFlangOutOfTreeBuildFactory from a test program, passing flang-aarch64-libcxx flags as llvm_extra_configure_args.

But it would be good to get some feedback to confirm this is the right approach, before testing it in a buildbot.

[Meinersbur]

I am not sure this can work and if it does it will be fragile. The reason is that the LLVM_ENABLE_RUNTIMES system itself sets CMAKE_CXX_COMPILER and which definition wins is nothing I would rely on. Why not adding -I<path-to-libcxx> to -DRUNTIMES_CMAKE_ARGS=-DCMAKE_CXX_FLAGS= so stage1 clang is able to find libcxx?

If a bootstrapping build is not possible, consider a standalone-runtimes build, like flang-runtime-cuda-clang does.

This current PR doesn't seem to use getFlangOutOfTreeBuildFactory for flang-aarch64-libcxx, but might be a solution as well.

[luporl]

This current PR doesn't seem to use getFlangOutOfTreeBuildFactory for flang-aarch64-libcxx, but might be a solution as well.

Right, flang-aarch64-libcxx uses getCmakeWithNinjaBuildFactory instead, I completely missed it...

[DavidSpickett]

Thanks for taking this up @luporl .

Why not adding -I to -DRUNTIMES_CMAKE_ARGS=-DCMAKE_CXX_FLAGS= so stage1 clang is able to find libcxx?

This works but requires us to 1. hardcode paths or 2. add stable symlinks to our docker container. Both are possible but not great for anyone external who needs to reproduce.

A standalone runtimes build would be ideal, and most "in the spirit" of the runtimes build. Assuming we can find a neat way to do it.

Using the out of tree builder means that flang is also out of tree, I think, so this bot becomes out of tree + libcxx. Normally I wouldn't want to mix concerns but we do have an out of tree bot to compare to at least. It would be clear if problems were due to using libcxx.

Maybe you can "out of tree" just flang-rt.