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

[Martin Storsjö via libcxx-commits]

mstorsjo 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:
> 
> ```shell
> 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.

Ah, I see! Right, yes, this commit will have changed where files are installed in this case.

> 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`.

Ok, so this is the missing clue that explains it to me. Previously, you didn't have clang actually consume the built libraries from the directory they were installed into, but moved them around into another path that clang does look in (based on another rule).

The intent of this commit, was that files are installed into a pathname where clang will look automatically, provided that it is invoked with the same target triple. Previously, it did install files into a directory that clang didn't look into, and hence you need to move/symlink files around.

> 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`.

Hmm, right. There are a couple of different codepaths that add lookup of libraries in a bunch of different directories - some based on the full triple (e.g. what `clang -print-target-triple`, which is what this change uses), some based on a different kind of normalization of triples, e.g. to match the debian style multiarch directories - https://github.com/llvm/llvm-project/blob/llvmorg-19-init/clang/lib/Driver/ToolChains/Gnu.cpp#L2453-L2455. I guess each tool in `ToolChains` might have different rules for what it tries to look for here - and I guess some may look for things in the non-normalized directory as well.

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