Building shared libraries without linking its dependencies (including transitive alwayslink dependencies).

[wudisheng]

Description of the feature request:

We have a scenario that we need to build some shared libraries as plugins (to be dynamically loaded, e.g. through dlopen), and then found the shared libraries built by Bazel are much larger than those by CMake, and fail to load due to some symbols.

We tried to build these shared libraries using cc_binary and cc_shared_library with various options, but Bazel ones still contain much more symbols than CMake ones.

To build these shared libraries, there are a deep tree of dependencies in and out of our control scope, some of the direct and transitive dependencies are marked alwayslink = 1, but we do not want any of them linked into these shared libraries --- i.e. we want these shared library contain only what in their srcs.

We can not refactor the dependencies to be interface libs and corresponding implementation libs (which the former provide headers only), we can use a custom Starlark rule to drop the linking_context in CcInfo to somewhat archive our goal, but it was too tricky and may bring some unwanted effects.

What underlying problem are you trying to solve with this feature?

As described above, an equivalent way of build shared libraries like in CMake.

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

release 6.2.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

.

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

Unrelated.

Have you found anything relevant by searching the web?

Not exactly.

Any other information, logs, or outputs that you want to share?

No at this time, can demonstrate and upload according to needs.

[oquenchil]

Just linking its sources is what cc_library does for both the *.a and the *.so files it creates.

[wudisheng]

Basically, we need the ability to EITHER

• create a new cc_library target which is the header-only part of an existing cc_library target; OR
• give cc_library rule an option like header_only_deps in which targets are not linked.

It is impossible for us to split all cc_library dependencies into their header-only and implementation targets.

[oquenchil]

give cc_library rule an option like header_only_deps in which targets are not linked.

Are you on Windows? Because except for Windows where linking transitive deps is necessary, this is what cc_library already does.

The dynamicLinkType for cc_library here is NODEPS_DYNAMIC_LIBRARY.

[brians-neptune]

I think cc_shared_library can solve this problem. Pull the shared dependencies out into one or more cc_shared_librarys, and then use those in dynamic_deps when linking the main binary and the plugins.