[9.1.0] fix copy_dynamic_libraries_to_binary for subdirectories

[novas0x2a]

Description / Motivation

This is a new instance of a similar problem described in #12448. In order for windows binaries to run, the (non-system) dlls need to be copied to the same directory. However, the code that determined that was only looking at the package label and the workspace, but not the actual subdirectory. Previously, this was fixed by adding the lib.is_source check, but this only solves it for source files (i.e. for cc_import) but not cc_library.

This is a crossport from rules_cc; See bazelbuild/rules_cc#623.

The bug is not present in bazel HEAD, because the cc code has been fully removed. However, the bug is present in all current release lines (9.x, 8.x, 7.x, 6.x). You can see this in the rules_cc pipeline from before I disabled this test in rules_cc for the versions that use the bazel native code.

Build API Changes

This could potentially be considered a breaking change; it makes copy_dynamic_libraries_to_binary behave like it said it would, but this bug has been present for so long that it is possible people have built workarounds for it into their code.

Checklist

• I have added tests for the new use cases (if any).
• [n/a] I have updated the documentation (if applicable).

The tests are in rules_cc; see bazelbuild/rules_cc#623.

Release Notes

RELNOTES: None

[armandomontanez]

@pzembrod FYI this backport of bazelbuild/rules_cc#623

[iancha1992]

cc: @hvadehra because src/main/starlark/builtins_bzl/common/cc/cc_binary.bzl was deleted in the master branch.

[hvadehra]

However, the bug is present in all current release lines (9.x, 8.x, 7.x, 6.x). You can see this in the rules_cc pipeline from before I disabled this test in rules_cc for the versions that use the bazel native code.

I don't see a failing run for Bazel 9 there.

This PR will have no effect - the cc rules embedded in Bazel 9 are unused, only those from @rules_cc get used.

If you want to backport this, it needs to be only for Bazel <= 8.

[novas0x2a]

The idea was to target the newest branch that still had the buggy code present (which is different than the test failing) and then trigger the auto-backport for the rest of the branches. If you're saying this code should already have been deleted from 9.1.0, well, yep, I agree with you, but it's still there nonetheless :)

[novas0x2a]

@hvadehra As far as I know, I can't trigger the bot backports, though, so... could you?

[novas0x2a]

Well, let's try anyway:
@bazel-io fork 8.7.0

[novas0x2a]

I didn't get a thumbs-up, so I assume it's not going to listen to me.

[hvadehra]

Just change the target of this PR to the release-8.7.0 branch instead

[hvadehra]

Might be simpler to just open a fresh PR?

[novas0x2a]

I opened the 8.x PR, but there's no release branch created for 7.x, so I'm not sure how to do this (you all might want to actually document this process for those of us outside google; this is sort of unpleasant).