Update: in https://github.com/RobotLocomotion/drake/pull/12262, I’ve written a cc_whole_archive_library(deps = ...) which is basically cc_library(alwayslink_deps = ...). It just rewrites libraries_to_link to add alwayslink = True to every edge, instead of forcing it to appear upstream. Anyone is welcome to reuse it (Apache-2.0) for yourselves if it helps.

@hlopko thanks for the advice. It’s a lot uglier than I’d like but it should work.

I realise my use case isn’t super common, but it doesn’t seem unreasonable either (“this .so target exists to be shipped standalone without dependencies, but the rest of the codebase wants to behave normally”). It seems odd to me that alwayslink has been put onto the depended-on targets rather than the final target? Why should my cc_library care whether you decide to link in the whole archive or not (meanwhile, the downstream target might be quite opinionated about how linking happens)?

I have the exact problem as @johnmarkwayve.

I have hundreds of small targets cc_library(linkstatic = 1) that are used both (1) by C++ applications with a main() routine (where we definitely do not want alwayslink = True for bloat reasons), and (2) by Python as a loaded module (as a single, large shared library composed of the small cc_library targets rolled into one).

Because the alwayslink is at the point of declaration instead of point of use (aka not on the edges), I can’t tag my small cc_library targets with it. But there seems to be no built-in way to roll up cc_library targets into a whole-archive shared library, which for my use case is a major regression and loss of capability.

It seems like at minimum an attribute like the alwayslink_deps proposed above should exist, so that I can write …

cc_library(
  name = "all.a",
  alwayslink = True,
  alwayslink_deps = [":small1", ":small2", ":small3"],
)

… at which point I could convert all.a into a cc_binary(all.so) shared library by writing one more simple rule.

The work-around of using a macro to declare two cc_library targets (one with and without alwayslink) is a non-starter. For one thing, it compiles all of the sources twice (even if I mark them as “manual” and only induce builds on the flavors that are actually used). For another, it gets us into a “red object” vs “blue object” world, where the deps lines need to be respelled inside the macro to have the correct color depending on whether the ultimate cc_binary is a program or a shared library.

For now my workaround is to implement a cc_whole_archive_library rule (see https://github.com/RobotLocomotion/drake/pull/12262) that repacks all objects into a single static archive, which I can then label with alwayslink = True. This is a bit gross from a scale perspective (build footprint and I/O) but appears to get the job done.

But in general I’d like if cc_library and/or cc_binary had the capability to deliver shared objects out of the box, instead of having to roll my own starlark for it.

I know I’m very late to the game here, but what’s the suggested mitigation? I had been using cc_binary with linkshared and linkstatic in a few places to force a build of a .so which contains all symbols of all dependencies so it could be shipped on its own. I only care about linking in these symbols in the few cases where I want to ship a dependency-free .so, so I definitely don’t want to pollute all of my other cc_library rules with alwayslink = True just to support this fairly rare use case?