Add empty linker_input object in Starlark cc_library

This was a difference between the native implementation of cc_library and its Starlark counter part. The linker_input objects are propagated via the linking_context in the CcInfo provider. Each linker_input object contains an owner; the owner is represented by the label of the target creating the linker_input.

In the case of native cc_library, even if a target didn't add any new user_link_flags, files or object files, it still created a linker_input object while Starlark cc_library didn't. An example target that wouldn't create an empty linker_input object in the Starlark implementation would be:
cc_libary(
    name = "foo",
    deps = [
       ":bar",
       ":baz",
    ]
)

At the same time, the cc_shared_library logic would use the owners that it would see in the graph to make conclusions about what to link where. The Starlark implementation of cc_library would cause problems in the following case (using foo from above):
cc_shared_library(
      name = "foo_shared",
      roots = [":foo"],
      static_deps = [ # This attribute is irrelevant for this problem.
           "//..."
      ]
)

cc_binary(
      name = "main",
      srcs = ["main.cc"],
      dynamic_deps = [":foo_shared"],
      deps = [":foo"]
)

Since foo (a root is considered an export) doesn't create a linker_input, we don't detect it here and prune its subtree: https://cs.opensource.google/bazel/bazel/+/master:src/main/starlark/builtins_bzl/common/cc/experimental_cc_shared_library.bzl;drc=ff927f72644b4d1c3036ea8b3b821c58c34c92fa;l=89. That's because it's not added to the can_be_linked_dynamically dictionary here: https://cs.opensource.google/bazel/bazel/+/master:src/main/starlark/builtins_bzl/common/cc/experimental_cc_shared_library.bzl;drc=ff927f72644b4d1c3036ea8b3b821c58c34c92fa;l=258

Therefore,if experimental_link_static_libraries_once is off (which is the case for Tensorflow) the algorithm in cc_shared_library deciding what to link into the cc_binary will link bar and baz again into the binary even though they were already linked into foo_shared. The error would have been caught earlier if the flag experimental_link_static_libraries_once had been True but the right behavior is not to attempt to link bar and baz into the binary since these targets are not reachable without going through a library that was exported by a shared library (i.e. the library foo which we didn't detect).

Fixes #16296

RELNOTES:none
PiperOrigin-RevId: 481127757
Change-Id: Ieb4a98002cc77ff751a9ae15773998aab350ece6
2 files changed
tree: ef9efebc082f748c232ab46f62568f814079ee16
  1. .bazelci/
  2. .github/
  3. examples/
  4. scripts/
  5. site/
  6. src/
  7. third_party/
  8. tools/
  9. .bazelrc
  10. .gitattributes
  11. .gitignore
  12. AUTHORS
  13. BUILD
  14. CHANGELOG.md
  15. CODE_OF_CONDUCT.md
  16. CODEOWNERS
  17. combine_distfiles.py
  18. combine_distfiles_to_tar.sh
  19. compile.sh
  20. CONTRIBUTING.md
  21. CONTRIBUTORS
  22. distdir.bzl
  23. distdir_deps.bzl
  24. LICENSE
  25. MODULE.bazel
  26. README.md
  27. SECURITY.md
  28. WORKSPACE
  29. WORKSPACE.bzlmod
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Reporting a Vulnerability

To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Contributing to Bazel

See CONTRIBUTING.md

Build status