bazel/compile/test: Fix negative compiler-rt tests by using explicit -rtlib=platform

[Copilot]

libclang_rt.builtins.a is physically overlaid into clang's resource directory by the libclang_rt attribute regardless of the compiler-rt flag — so clang auto-discovers it even when --@toolchains_llvm//toolchain/config:compiler-rt=False is set, causing __divti3 to remain defined and the negative tests to fail.

Changes

• New cc_binary target test_compiler_rt_no_rt — same source as test_compiler_rt but adds linkopts = ["-rtlib=platform"] to explicitly suppress clang's resource-directory auto-discovery of compiler-rt builtins:

cc_binary(
    name = "test_compiler_rt_no_rt",
    srcs = ["test_compiler_rt.cc"],
    copts = ["-Werror"],
    linkopts = ["-rtlib=platform"],
)

• Negative test targets (cross_compile_aarch64_no_compiler_rt_test, cross_compile_x86_64_no_compiler_rt_test) updated to use :test_compiler_rt_no_rt in both data and env.BINARY — positive tests remain on :test_compiler_rt unchanged.

Original prompt

Problem

In PR envoyproxy#3851 (branch bazel-compile-rt), the negative compiler-rt tests (cross_compile_aarch64_no_compiler_rt_test and cross_compile_x86_64_no_compiler_rt_test) are failing because __divti3 is still showing up as a defined symbol even when --@toolchains_llvm//toolchain/config:compiler-rt=False is passed.

Root Cause

The libclang_rt attribute in toolchains_llvm.bzl physically copies libclang_rt.builtins.a into the LLVM distribution's resource directory (lib/clang/<version>/lib/linux/) during the download_llvm repository rule phase (see toolchain/internal/llvm_distributions.bzl line ~838 in bazel-contrib/toolchains_llvm).

The compiler-rt config flag in toolchains_llvm controls a select() in cc_toolchain_config.bzl (line 475):

link_flags = link_flags + 
    select({...: "use_libunwind"}: libunwind_link_flags, "//conditions:default": []}) +
    select({...: "use_compiler_rt"}: compiler_rt_link_flags, "//conditions:default": []})

Where compiler_rt_link_flags = ["-rtlib=compiler-rt"].

When compiler-rt=True (the default): -rtlib=compiler-rt is passed → clang uses compiler-rt.
When compiler-rt=False: nothing is passed ([]) → but clang still auto-discovers libclang_rt.builtins.a from its resource directory because the file physically exists there from the overlay.

Fix

The cc_binary target test_compiler_rt needs to explicitly tell clang NOT to use compiler-rt when the test expects it to be absent. The cleanest approach matching existing toolchains_llvm patterns is to add linkopts = ["-rtlib=platform"] to the cc_binary target used by the negative tests, or better yet, create a separate cc_binary with that linkopt for the negative tests.

However, since we can't change the toolchain's select() default branch from this repo (that would be an upstream toolchains_llvm change), the best approach within envoyproxy/toolshed is:

1. Create a second cc_binary target (e.g. test_compiler_rt_no_rt) that adds linkopts = ["-rtlib=platform"] to explicitly override clang's auto-discovery of compiler-rt builtins from the resource directory.
2. Update the negative sh_test targets to use this new binary instead of :test_compiler_rt.

This mirrors how clang's -rtlib= flag works:

• -rtlib=compiler-rt → use compiler-rt builtins (explicit opt-in)
• -rtlib=platform → use platform default (libgcc), even if compiler-rt exists in the resource dir

Files to change

All in bazel/compile/test/:

BUILD.bazel

Add a new cc_binary:

cc_binary(
    name = "test_compiler_rt_no_rt",
    srcs = ["test_compiler_rt.cc"],
    copts = ["-Werror"],
    linkopts = ["-rtlib=platform"],
)

Update the two negative test targets (cross_compile_aarch64_no_compiler_rt_test and cross_compile_x86_64_no_compiler_rt_test) to reference :test_compiler_rt_no_rt instead of :test_compiler_rt in both data and env.BINARY.

No changes needed to check_compiler_rt.sh or test_compiler_rt.cc

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: everything works here except for the no rt test - its still pulling it in

original agent attempt had a patch - but it wasnt needed afaict - at least not for tests - the reverse is true - somethign needs to prevent it being pulled in i think

Assistant:

Let me look at the PR and understand the issue with the "no rt" test.

Assistant: Now let me look at how toolchains_llvm handles the compiler-rt config flag and how the libclang_rt attribute interacts with it:

Assistant: Now I can see the key issue. Let me look more closely at how compiler_rt_link_flags is set up and how the libclang_rt attribute in toolchains_llvm interacts with the linker files.

Assistant: Now I understand the full picture. Let me look at how compiler_rt_link_flags is constructed and how it interacts with the libclang_rt overlay to understand why compiler-rt=False isn't preventing the library from being linked.

Assistant: Now I have a clear picture of the problem. Let me look at how the cc_binary test_compiler_rt is built — specifically, the key issue is that the libclang_rt library is physically copied into the LLVM distribution's lib/clang/<version>/lib/ directory during download_llvm. This means the library is always present in the distribution, regardless of the --@toolchains_llvm//toolchain/config:compiler-rt=False flag.

The flag only controls whether -rtlib=compiler-rt is passed as a link flag (via compiler_rt_link_flags). But the LLVM distribution's lib filegroup already includes lib/clang/{LLVM_VERSION}/lib which now contains the overlaid libclang_rt.builtins.a. The linker/clang may automatically discover and link against libclang_rt.builtins.a from its resource directory, even without the explicit -rtlib=compiler-rt flag.

Here's the core problem:

1. In toolchains_llvm.bzl, the `libcl...

This pull request was created from Copilot chat.

---

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.