Description of the feature request:

Bazel's new CC Starlark API allows users to create LibraryToLink objects using create_library_to_link. The current implementation imposes preserveName = true and prefixConsumer = true for dynamic libraries. Please expose these flags to the user and allow overriding the default values.

Feature requests: what underlying problem are you trying to solve with this feature?

With create_library_to_link dynamic libraries will be placed under the global _solibs directory. With preserveName = true Bazel generates an additional directory and places the library under _solibs/<extra-dir>/<unmangled-lib>. Additionally, prefixConsumer = true causes <extra-dir> to be made up of the package path to the library target as well as the package path to the consumer of the library. These paths can become rather large.

On MacOS the MACH-O header size is limited to 32k. If a target depends on many dynamic libraries, which require long load-commands or rpath-entries, then this limit can quickly be exceeded.

With rules_haskell we have frequently encountered issues with the MACH-O header size limit in practice. rules_haskell already employs several work-arounds to avoid this issue. Currently, it is not possible for rules_haskell to make full use of the CC Starlark API and define Haskell build results with create_library_to_link, because the resulting load commands would exceed the MACH-O header size limit in practice.

With preserveName = false rules_haskell could make use of Bazel's builtin name mangling to avoid library name conflicts, while achieving sufficiently short load commands. Also, rules_haskell requires stable library names across consumers, which prefixConsumer = false would provide.

What operating system are you running Bazel on?

MacOS Mojave 10.14.4

What's the output of bazel info release?

release 0.24.0- (@non-git)

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

nixpkgs