Repository: bazelbuild/bazel
Issue: Regression: cc_import not linked to target when added to deps of target
Labels: type: bug
P1
team-Rules-CPP

### Description of the bug:


Since bazelisk moved us to 6.3.0 yesterday, our libraries have not linked. This is a regression in 6.3.0 vs 6.2.0


### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.



http_archive('a')
cc_import(name='b', interface_library=b.lib, shared_library=b.dll)

cc_library(name='c_base', srcs=[x,y,z], deps=['@a//:b'])
cc_shared_library(name='c', deps=[":c_base"])

6.2.0: c_base links fine, linker params file includes b.lib
6.3.0: c_base not linked, linker params file is missing b.lib

### Which operating system are you running Bazel on?


Windows

### What is the output of `bazel info release`?


release 6.3.0

### 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.


Between 6.2.0 and 6.3.0, will try to run bisect

### Have you found anything relevant by searching the web?

No

### Any other information, logs, or outputs that you want to share?

_No response_

Issue comments:
cc @oquenchil 
Your bisect is likely to land on https://github.com/bazelbuild/bazel/commit/946777ab77ec84223b02b4deb2d7d947a4ab3611, which combines multiple individual commits to master. Could you check whether the issue reproduces with `last_green`?
bazelisk --bisect does not work for me, is it supported by Windows bazelisk?

last_green gives me a different error:
`Error in fail: Two shared libraries in dependencies link the same library statically. Both @//src/a:liba and @//src/b:libb link statically @//src:include_root
`

This diagnostic is correct, but unhelpful; src/include_root is a header-only library and thus has nothing to link.


CC @meteorcloudy who implemented `--bisect`


> bazelisk --bisect does not work for me, is it supported by Windows bazelisk?

Yes, it should work for Windows. Can you provide the error messages you get while running bazelisk bisect?
@bazel-io fork 6.3.1
@bazel-io fork 6.4.0
I'm debugging this now. The code was never written to work like this because it discarded pre-compiled dynamic libraries (or at least that was the intention). So it was an accident that it worked for 6.2.

However, the bug report is valid because on Windows the transitive *.libs should be passed to the linker for DLL creation so this needs to be fixed. This doesn't apply on other platforms, for other platforms `b` shouldn't have to appear in the command line of `c`.
Actually what I said in my previous comment is completely wrong. This is working at head by the way, I thought you had checked at last_green. This also affects Linux.

The issue here is that `cc_import` in 6.x doesn't advertise CcInfo when it should, i.e.: this line https://cs.opensource.google/bazel/bazel/+/master:src/main/starlark/builtins_bzl/common/cc/cc_import.bzl;drc=6ce7a5455640984f69c69d534db61d9c1873a9f0;l=212 is missing
Fix is in https://github.com/bazelbuild/bazel/pull/19086/commits
@chrisbrown2050 Thank you for reporting this issue.
We're looking to improve our release process so that we can catch more issues early on in the cycle (before the final release) and would love your input. What can we do to make it easier for you to test _release candidates_ in the future? 
@chrisbrown2050 Can you please confirm if this issue has been fixed in 6.3.1rc1?
6.3.1rc1 does fix this issue - thank you!

As to how we could test _release candidates_, right now I don't track these. But now I know I can test them via bazelisk, it's pretty easy. How would I subscribe to notifications? Or can I set an environment var so my own machine updates to all the release candidates whilst all our production machines stay on official releases?
@peakschris Thanks for confirming! Yes, with bazelisk, you can point to the latest rc by setting `USE_BAZEL_VERSION=last_rc`, see https://github.com/bazelbuild/bazelisk#how-does-bazelisk-know-which-bazel-version-to-run

@keertk It's probably worth advertising this approach ;)

Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/starlark/builtins_bzl/common/cc/cc_import.bzl b/src/main/starlark/builtins_bzl/common/cc/cc_import.bzl
index babfb2b40c989e..b7c7ff8df636c7 100644
--- a/src/main/starlark/builtins_bzl/common/cc/cc_import.bzl
+++ b/src/main/starlark/builtins_bzl/common/cc/cc_import.bzl
@@ -220,6 +220,7 @@ cc_import = rule(
         ),
         "_cc_toolchain": attr.label(default = "@" + semantics.get_repo() + "//tools/cpp:current_cc_toolchain"),
     },
+    provides = [CcInfo],    
     toolchains = cc_helper.use_cpp_toolchain(),
     fragments = ["cpp"],
     incompatible_use_toolchain_transition = True,


Test patch:
diff --git a/src/main/starlark/tests/builtins_bzl/cc/cc_shared_library/test_cc_shared_library/BUILD.builtin_test b/src/main/starlark/tests/builtins_bzl/cc/cc_shared_library/test_cc_shared_library/BUILD.builtin_test
index 952dea0c426454..196231642e74e2 100644
--- a/src/main/starlark/tests/builtins_bzl/cc/cc_shared_library/test_cc_shared_library/BUILD.builtin_test
+++ b/src/main/starlark/tests/builtins_bzl/cc/cc_shared_library/test_cc_shared_library/BUILD.builtin_test
@@ -405,12 +405,10 @@ paths_test(
     name = "path_matching_test",
 )
 
-cc_library(
+cc_import(
     name = "prebuilt",
     hdrs = ["direct_so_file_cc_lib.h"],
-    srcs = [
-        ":just_main_output",
-    ],
+    shared_library = ":just_main_output",
 )
 
 filegroup(