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