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, use the out of tree flang builder to build llvm,
flang and flang-rt with the host compiler, using libcxx.

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.

[luporl]

As suggested, the last commit adopts a new approach, by using the out of tree flang builder to build llvm,
flang and flang-rt with the host compiler, using libcxx. This way, no modifications are needed in the flang builder, just in the builder config.

I haven't tried to "out of tree" just flang-rt, because it would create another "special case", that would require modifications to the flang builder and would be used only by flang-aarch64-libcxx. Instead, it's similar to flang-aarch64-out-of-tree, and can be compared to it on failures. The main differences are that it uses libcxx and shared libraries.

I've used a local buildbot environment to test this and it works fine.

[DavidSpickett]

LGTM

Thanks for taking care of this.

[luporl]

Thanks @DavidSpickett and @Meinersbur, for the reviews and suggestions.

[DavidSpickett]

Thanks for the fix Leandro, it's now building correctly - https://lab.llvm.org/staging/#/builders/46/builds/4084.

1 failure but we know this is due to #482.