`cc_shared_library` dependency of `cc_test` results in redundant shared objects in runfiles

[brians-neptune]

Description of the bug:

When a cc_test depends on a cc_shared_library, it correctly links against the cc_shared_library. However, the cc_library shared object still ends up in runfiles. This results in building all of the (transitive) dependencies twice.

Which category does this issue belong to?

C++ Rules

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

https://github.com/brians-neptune/bazel-cc_shared_library-cc_test has a pretty minimal example. Here's the BUILD file, all the C/C++ files are empty (except for an empty main in test.cc):

cc_library(
    name = "dep",
    srcs = ["dep.cc"],
    hdrs = ["dep.h"],
)

cc_shared_library(
    name = "dep_shared",
    deps = [":dep"],
)

cc_test(
    name = "test",
    srcs = ["test.cc"],
    dynamic_deps = [
        ":dep_shared",
    ],
    deps = [":dep"],
)

liblibdep.so and libdep_shared.so are both in runfiles:

$ bazel cquery --output=starlark --starlark:expr='target.data_runfiles.files' test
INFO: Analyzed target //:test (1 packages loaded, 6 targets configured).
INFO: Found 1 target...
depset([<generated file _solib_k8/liblibdep.so>, <generated file libdep_shared.so>, <generated file _solib_k8/_U/libdep_shared.so>, <generated file test>], order = "postorder")

but only libdep_shared.so is actually used:

$ ldd bazel-bin/test
    linux-vdso.so.1 (0x00007fff5ccd8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007e330095c000)
    libdep_shared.so => /home/brian/Desktop/bazel-cc_shared_library-cc_test/bazel-bin/_solib_k8/_U/libdep_shared.so (0x00007e3300958000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007e3300600000)
    /lib64/ld-linux-x86-64.so.2 (0x00007e3300a60000)

Which operating system are you running Bazel on?

Ubuntu 22.04

What is the output of bazel info release?

release 7.0.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[keith]

passing --dynamic_mode=off might workaround this (but might not be desirable)

[comius]

cc @pzembrod for triage cc @oquenchil for potential insights

[oquenchil]

Very likely that this must be fixed on the cc_test side, not cc_shared_library. The implementation already filters out the nodeps *.so that don't need to be linked, I don't remember adding code to filter out those same files from runfiles which would explain this behavior.

[oquenchil]

If this affects cc_test, then it probably affects cc_binary with linkstatic = 0. The code path is the same, so fixing one should fix the other.