Transitive shared libraries not added to rpath of otherwise static binaries about buck2

[cjhopman]

Personally I think it's just a bug and would love to see us fix it.

But, it's actually more that the behavior in the condition is wrong, but for the shared link case it's less wrong. Okay, what's going on? The d.shared_library_info there ends up being basically a list of all the shared libraries in the graph for every target that can produce a shared library (basically, every target with preferred_linkage = "any" or "shared" ends up with an entry in the shared_library_info).

When using link_style = "static" (actually if used anywhere in the graph, not just at the top level like that condition checks) that list of libraries might include a bunch that you don't actually use (because it would include ones from targets with preferred_linkage = any even though you consume those as shared libs).

The right way to do this is that we should be tracking up the actual shared lib deps of each shared lib, rather than just stuffing everything into shared_library_info and using that.

[cbarrete]

Tagging @cjhopman since you already had the answers last time, I hope you don't mind.

[cbarrete]

I did some digging and it seems to come from

    # Only setup a shared library symlink tree when shared linkage or link_groups is used
    gnu_use_link_groups = cxx_is_gnu(ctx) and link_group_mappings
    shlib_deps = []
    if link_strategy == LinkStrategy("shared") or gnu_use_link_groups:
        shlib_deps = (
            [d.shared_library_info for d in link_deps] +
            [d.shared_library_info for d in impl_params.extra_link_roots]
        )

in cxx_executable (cxx/cxx_executable.bzl).

Removing the check seems to do what I want, but that might break something elsewhere?
The alternative seems to be to use link groups but:

1. I don't know what those are and couldn't really find documentation about them
2. They seem to only be supported with GCC, which is a dealbreaker for us

Can I get some context regarding why this check was added? If it's some sort of optimization, I would suggest removing it, unless:

1. it was proven to be slowing things down in static builds
2. there's another way of handling the use-case for this issue