[Driver] Old compiler-rt library name (e.g. libclang_rt.builtins-aarch64.a) is reported when neither old/new library directory exists

[wzssyqa]

When we build llvm with this cmd

cmake ../llvm -G Ninja -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_RUNTIMES="compiler-rt;libunwind" -DLLVM_ENABLE_PROJECTS="mlir;clang;clang-tools-extra;lld" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=RelWithDebInfo

It builds successfully, while if we try do something like

./bin/clang --rtlib=compiler-rt hello.c

Something wrong happens

/usr/bin/aarch64-linux-gnu-ld: cannot find <PATH>/build-aarch64/lib/clang/19/lib/linux/libclang_rt.builtins-aarch64.a: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

libclang_rt.builtins-aarch64.a does exists, while in a different path, with a different name

./lib/clang/19/lib/aarch64-linux-gnu/libclang_rt.builtins.a

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: YunQiang Su (wzssyqa)

When we build llvm with this cmd

cmake ../llvm -G Ninja -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_RUNTIMES="compiler-rt;libunwind" -DLLVM_ENABLE_PROJECTS="mlir;clang;clang-tools-extra;lld" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=RelWithDebInfo

It builds successfully, while if we try do something like

./bin/clang --rtlib=compiler-rt hello.c

Something wrong happens

/usr/bin/aarch64-linux-gnu-ld: cannot find <PATH>/build-aarch64/lib/clang/19/lib/linux/libclang_rt.builtins-aarch64.a: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

libclang_rt.builtins-aarch64.a does exists, while in a different path, with a different name

./lib/clang/19/lib/aarch64-linux-gnu/libclang_rt.builtins.a

[wzssyqa]

Maybe we should fix our build system to always set the directory to the normalized one?

@MaskRay

[MaskRay]

cmake ../llvm -G Ninja -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_RUNTIMES="compiler-rt;libunwind" -DLLVM_ENABLE_PROJECTS="mlir;clang;clang-tools-extra;lld" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=RelWithDebInfo

Are you building a x86-64 clang that produces aarch64 code on an x86-64 host? The command line does not look correct to me.

I've used the following using /tmp/Rel/bin/clang. LLVM_HOST_TRIPLE is important

cmake -GNinja -Sllvm -B/tmp/out/a64-0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/tmp/Rel/bin/clang -DCMAKE_CXX_COMPILER=/tmp/Rel/bin/clang++ -DCMAKE_{C,CXX}_FLAGS='--target=aarch64-linux-gnu' -DLLVM_NATIVE_TOOL_DIR=/tmp/Rel/bin -DLLVM_HOST_TRIPLE=aarch64-linux-gnu -DLLVM_TARGETS_TO_BUILD=AArch64

/usr/bin/aarch64-linux-gnu-ld: cannot find <PATH>/build-aarch64/lib/clang/19/lib/linux/libclang_rt.builtins-aarch64.a: No such file or directory

Newer Clang will not suggest libclang_rt.builtins-${arch}.a. See https://discourse.llvm.org/t/runtime-directory-fallback/76860

[wzssyqa]

cmake ../llvm -G Ninja -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_RUNTIMES="compiler-rt;libunwind" -DLLVM_ENABLE_PROJECTS="mlir;clang;clang-tools-extra;lld" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=RelWithDebInfo

Are you building a x86-64 clang that produces aarch64 code on an x86-64 host? The command line does not look correct to me.

Yes, the normal 'cross toolchain', just like (almost) all embedded cross toolchain with GCC.
In fact I am trying to run mips test with qemu-user.
"Not correct" means that we don't support the change the default output arch on build time?

I've used the following using /tmp/Rel/bin/clang. LLVM_HOST_TRIPLE is important

cmake -GNinja -Sllvm -B/tmp/out/a64-0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/tmp/Rel/bin/clang -DCMAKE_CXX_COMPILER=/tmp/Rel/bin/clang++ -DCMAKE_{C,CXX}_FLAGS='--target=aarch64-linux-gnu' -DLLVM_NATIVE_TOOL_DIR=/tmp/Rel/bin -DLLVM_HOST_TRIPLE=aarch64-linux-gnu -DLLVM_TARGETS_TO_BUILD=AArch64

It is not "normal" cross toolchain.
This cmd will generate a native ARM64 toolchain instead of a cross toolchain for ARM64.

/usr/bin/aarch64-linux-gnu-ld: cannot find <PATH>/build-aarch64/lib/clang/19/lib/linux/libclang_rt.builtins-aarch64.a: No such file or directory

Newer Clang will not suggest libclang_rt.builtins-${arch}.a. See https://discourse.llvm.org/t/runtime-directory-fallback/76860

Yes. That's a bug then.
I noticed some code in ToolChain::getCompilerRT/clang/lib/Driver/ToolChain.cpp

  // Check the filename for the old layout if the new one does not exist.
  CRTBasename =
      buildCompilerRTBasename(Args, Component, Type, /*AddArch=*/true);
  SmallString<128> OldPath(getCompilerRTPath());
  llvm::sys::path::append(OldPath, CRTBasename);
  if (Path.empty() || getVFS().exists(OldPath))     // <----------------  **Path will be empty in this case.**
    return std::string(OldPath);

  // If none is found, use a file name from the new layout, which may get
  // printed in an error message, aiding users in knowing what Clang is
  // looking for.
  return std::string(Path);

I have tried to fix this problem. See: #87319

[wzssyqa]

In fact, it will fail even for native toolchain, if the -DLLVM_DEFAULT_TARGET_TRIPLE is given with a non-normalized triple.
We have two way:
1. Also search the subdir what -DLLVM_DEFAULT_TARGET_TRIPLE gives us, just as wzssyqa@b0be3f9
2. Fix our build system, install libclang_rt into a normalized subdir always.

[MaskRay]

I think the issue is at ToolChain::getTargetSubDirPath. When the directory does not exist, we should still add it to getLibraryPaths() so that ToolChain::getCompilerRT will report the new compiler-rt file path.

I am testing a fix for ToolChain::getTargetSubDirPath