Add supports_interface_shared_libraries to cc_shared_library

[keith]

This also backfills tests and fixes this in the default unix toolchain

[keith]

i could split the unix toolchain fix up but it was nice to verify with this new support

[keith]

this is still off by default and requires users pass --features=supports_interface_shared_libraries

[keith]

this working on macOS depends on #675

[keith]

cc @fmeum in case there was a reason not to do this originally

[fmeum]

I don't see why it shouldn't work.

[lilygorsheneva]

Getting a failure in tests that are still in main Bazel repo.
https://github.com/bazelbuild/bazel/blob/708b25f5716af27cce53c797d149a73bf2dbdf66/src/main/starlark/tests/builtins_bzl/cc/cc_shared_library/test/BUILD.builtin_test#L367

value of: collection
1 expected elements missing from values:
  0: -lprivate_lib_so

Investigating.

[lilygorsheneva]

Disabling interface_shared_objects in that test fixes it; that being said is the change in default behavior expected? Still waiting on additional testing to see if this breaks actual users.

[keith]

can you tell from the log if there's a nodeps version of that lib in there? i think disabling that feature is fine for the tests, i guess that test is using the default --dynamic_mode value so it really is changing what is linked

[lilygorsheneva]

A .../libprivate_lib_so.ifso appears in the list

[keith]

yea i think that behavior is an expected change here. but if that test also works on macOS we probably still need to disable this feature for it. i think we should just disable that feature since it's unrelated to simplify

[pzembrod]

Hi Keith, could you sync this PR to head again? It looks like I'll need to manually import it to double-check internal test failures, and the import fails with "Cannot find a merge reference for Pull Request 680. It might have a conflict with head."

[keith]

rebased and green! conflicts were just adding new features in the tests in 2 prs at once

[lilygorsheneva]

Looks like I missed some things after disabling interface_shared_objects specifically in the link order test; the python_test and cc_test (in the cc_shared_library builtins test) fail to load the renamed_so_file. (didn't show up in the initial failures due to happening at normal test runtime instead of at analysis test runtime)

the python test tries to load the shared lib and fails. This might be a case of "we need to turn off interface shared libs for this use-case" but we'd need to communicate that.

cc_shared_library_integration_test uses the cc_test as data and fails to execute that binary; this feels like something actually going wrong

This one's a bit more confusing/cryptic; I'd expect more CI failures than just that if there was an issue loading shared libs.

p.s. I need to give migrating those tests out of the bazel repo another shot; currently in review for that.