bazelbuild / bazelbuild/bazel

Runfiles are not forwarded from `cc_library` to `cc_shared_library`

Open
#26,201 2 comments 1 reaction 0 assignees View on GitHub
P3 team-Rules-CPP type: bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.