Runfiles are not forwarded from `cc_library` to `cc_shared_library`
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
When a cc_library has data dependencies, those files should show up in downstream executables. This is the case for a `cc_library` -> `cc_binary`. However, if the chain is `cc_library` -> `cc_shared_library` -> `cc_binary`, the runfiles don't get forwarded correctly.
This is related to #21833, which is more specific about the shared library not being handled correctly in the runfiles.
Also related #26028.
This is what I am observing:
**`cc_library`:**
* data dependencies show up in the runfiles correctly
* the dynamic library of this target (not the dependencies) shows up in the `data_runfiles`, not the `default_runfiles`.
**`cc_shared_library`:**
* only the "shared" dynamic libraries show up in the runfiles (both `data_runfiles` and `default_runfiles`)
**`cc_binary`/`cc_test` with a `deps`/`dynamic_deps` pair with `linkstatic=True`:**
* `deps` runfiles show up correctly, no duplicate shared library
**`cc_binary`/'cc_test`: with a `deps`/`dynamic_deps` pair with `linkstatic=False`:**
* `deps` runfiles show up, including the dynamic library of the `deps` next to the "shared" dynamic library (see issue #21833).
**`cc_binary`/`cc_test`: with a `cc_shared_library` as `data` dependency:**
* the "shared" dynamic libraries show up correctly, but all of the upstream `data` dependencies are missing.
### 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.
```python
# BUILD.bazel file
# empty files `dep.hpp/dep.cpp
# `main.cpp` with a main function
cc_library(
name = "dep",
srcs = ["dep.cpp"],
hdrs = ["dep.hpp"],
data = ["BUILD.bazel"], # <--- adding a data dependency required as runtime resource
)
cc_shared_library(
name = "dep_shared",
deps = [":dep"],
)
cc_binary(
name = "test",
srcs = ["test.cc"],
data = [":dep_shared"],
)
```
The file `BUILD.bazel` is missing in the runfiles of the test:
```
bazel-bin/baz/test.runfiles
├── my_repo
│ ├── baz
│ │ ├── libdep_shared.so
│ │ └── test
│ └── _solib_k8
│ └── _Ubaz
│ └── libdep_shared.so
├── MANIFEST
└── _repo_mapping
```
cc @fmeum @oquenchil @pzembrod
### Which operating system are you running Bazel on?
Linux
### What is the output of `bazel info release`?
release 7.4.1
### 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` ?
```text
```
### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
_No response_
### Have you found anything relevant by searching the web?
https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1748660418918899
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Reproduce the issue with the BUILD.bazel example: cc_library data flows through cc_shared_library to a cc_binary that uses it as a data dependency. Inspect the runfiles produced for the test and compare them with the expected upstream BUILD.bazel file. Done means the upstream data dependency is present in the downstream binary's runfiles without breaking the existing shared-library entries.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100