-
Notifications
You must be signed in to change notification settings - Fork 434
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add opt-out from merging cc_lib object files in bindgen (#2959)
This is a ~rollback of #2590, as it turns out the current behavior is incomatible with https://bazel.build/docs/user-manual#dynamic-mode (which is very hard to use in the OSS because of bazelbuild/bazel#4135). In short, the dynamic mode works as follows: * Each cc_library produces object files that are used to produce * a static library (often not materialized but objects get passed as `--start-lib`/`--end-lib` to the linker), * a shared library (only containing the objects, not transitive dependencies), * and an interface library (produced from .so by "stripping function bodies"). * When linking binaries, by default we use the static linking. * When linking tests, by default we use interface libraries for linking, and shared libraries for test execution. The motivation for this is to avoid lengthy linking actions when all that has changed between previous build is the method body (therefore Bazel produces the same interface library, so we don't need to reexecute linking action). We do not support dynamic mode in rules_rust yet. The current bindgen behavior works by taking object from `cc_lib`, and merging them into the `rlib` output. When dynamic_mode is on, we now have a linking action that has the rlib early on the command line, and then interface libraries of dependencies of the `cc_lib`, and then the interface library of the `cc_lib`. For reasons, lld prefers statically defined symbols, it sees that the `rlib` defines the same symbols as `cc_lib` but statically, and errors out with `backward reference detected`, even though `cc_lib` is positioned correctly. The fix for us is to not merge objects.
- Loading branch information
Showing
4 changed files
with
85 additions
and
17 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters