[compiler-rt] [libcxx] CompilerRT: Normalize COMPILER_RT_DEFAULT_TARGET_TRIPLE (PR #89234)

[Peter Waller via llvm-commits]

peterwaller-arm wrote:

> That is - which change here is it that has changed where clang looks for things?

I'm unclear where the breakage happened. I was building a toolchain with something like:

```sh
ARGS=(
    "-DLLVM_ENABLE_RUNTIMES=compiler-rt"
    "-DLLVM_BUILTIN_TARGETS=aarch64-none-elf;aarch64-unknown-linux-gnu;aarch64-unknown-linux-musl"
    "-DBUILTINS_aarch64-none-elf_COMPILER_RT_SOME_FLAG=..."
    "-DLLVM_RUNTIME_TARGETS=aarch64-none-elf"
    "-DRUNTIMES_aarch64-none-elf_COMPILER_RT_SOME_FLAG=..."
)
```

With recent changes landed[0], the installed paths to the binaries changed. I think a different process outside of llvm-project set up to make things work (symlinking some paths into `/lib/clang-runtimes/`) ceased working because compiler-rt now gets installed to `aarch64-none-unknown-elf`. Fixing that process to use the correct fully qualified triple (`aarch64-unknown-none-elf`) isn't enough, even if the cmake invocation above is updated to use a full triple, because it still creates a disagreement in the triple normalization when the user then specifies a compiler invocation with `aarch64-none-elf`.

In summary, I think the breakage is caused by this change because there exists other things in the wild which expect `--target=aarch64-none-elf` to resolve at some point `/lib/aarch64-none-elf` or `/lib/aarch64-unknown-none-elf`, but this PR has the consequence of moving libraries to `aarch64-none-unknown-elf`.

[0] (and I suspect this commit specifically we're commenting on but *don't* have absolute confirmation other than a suspicion from seeing build after the revert of this patch fix it and then it broke again after it relanded).




https://github.com/llvm/llvm-project/pull/89234