tree ef9efebc082f748c232ab46f62568f814079ee16
parent 4779553eb5814025a465ebadbbced5c158996660
author Googler <plf@google.com> 1665752743 -0700
committer Copybara-Service <copybara-worker@google.com> 1665752837 -0700

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