Libraries exported by cc_shared_library can be dropped by the linker
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
If a library (without `alwayslink = True`) is exported by a cc_shared_library but unused, the linker drops the library. This is problematic since if a shared library (`A`) depends on a shared library (`B`), it expects any of its dependencies that are exported by `B` to be fulfilled by `B`, and therefore does not link them into `A`. The only way of avoiding this is to specify this dropped library in `deps`.
I would expect libraries that match the exports filter to be treated as if they were alwayslink, i.e. not put them inside `-Wl,--start-lib` and `-Wl,--end-lib`.
There is a slack thread about this here: https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1701702759075819
### Which category does this issue belong to?
_No response_
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I have created a reproducer of this issue here: https://github.com/cameron-martin/bazel-7-cc-shared-library-dropping-exported
Running `bazel build //:bin` reproduces this error, getting a linker error due to the dropped library.
### Which operating system are you running Bazel on?
Ubuntu 20.04
### What is the output of `bazel info release`?
release 7.0.0rc5
### 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 master; 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_
Contributor guide
Research direction
Start with the linked reproducer and run `bazel build //:bin` to observe the linker failure. Trace how `cc_shared_library` applies its exports filter and handles unused libraries, then verify that an exported library is retained without adding it to `deps`.
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
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100