cc_import does not propagate its shared_library runfiles

[kkubiak-arista]

In cases where the shared_library attribute in cc_import is not a plain file label, but for example a cc_shared_library target it can have its own runfiles that are currently ignored by cc_import instead of being propagated.

[lilygorsheneva]

On the cc_import side this is straightforward; however cc_shared_library itself has surprising runfiles behavior (only forwarding runfiles for ctx.attr.dynamic_deps).

rules_cc/cc/private/rules_impl/cc_shared_library_impl.bzl

Lines 732 to 733 in 7d32823

	for dep in ctx.attr.dynamic_deps:
	runfiles = runfiles.merge(dep[DefaultInfo].data_runfiles)

There's tests that expect this specific behavior.

https://github.com/bazelbuild/bazel/blob/3b1112d06ad05e85117b32608e1916fe256029bc/src/main/starlark/tests/builtins_bzl/cc/cc_shared_library/test/starlark_tests.bzl#L223-L247

@trybka who would know why we specifically have/expect that behavior?

[keith]

cc @fmeum

[keith]

i probably fixed the original report w/ #631

[lilygorsheneva]

In the specific case of a shared_library having deps with a (maybe-transitive) data field (which seems like a reasonable interpretation of the original report) I think #631 might need 2-4 extra lines in cc_import and cc_shared_library to handle.

But also since cc_import is meant for precompiled files maybe we shouldn't want to support that anyway.

[lilygorsheneva]

@oquenchil (Tom suggests asking you)

[trybka]

It looks like there has been some subtle changes/behavior (e.g. bazelbuild/bazel#19378 ) to this space.

I imagine we want to ensure we're not pulling in symlinks / dylibs for the libs that are statically linked, only those that are dynamically linked. But then there are presumably data files that are important to forward along.

[lilygorsheneva]

#673 also tries to implement the cc_shared_library-side change (and presumably ran into the same issue)