-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make linking the same shared library twice a rule error
> As more and more people start using the power of Starlark transitions, we are seeing more people bumping into a precondition baked deep in the C++ rules implementation which checks that a shared library being linked is in the same configuration directory. The check is there to make sure that the same library built in different configurations is not linked more than once. > Aside from the fact that it should be a proper rule error and not a crash, people are hitting this check when writing cc_import targets that have a transition applied to them. There are other ways to guarantee that the same library is not linked more than once without completely restricting the ability to link a library built in a different configuration. @oquenchil This PR makes linking the same shared library twice a rule error instead of a crash and it makes it possible to link a library built in a different configuration. A map from library identifiers to library paths is introduced, making sure that each shared library is linked at most once. Only dynamic linking is taken into account, for static linking see #11727 Fixes #11167 (the check which was causing the NPE was not directly related to transitions, but because it was removed, that NPE should no longer happen) Closes #11721. PiperOrigin-RevId: 322563028
- Loading branch information
1 parent
c1a4f91
commit a90c408
Showing
5 changed files
with
227 additions
and
51 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
Oops, something went wrong.
a90c408
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@agluszak I see you removed the check and the error "Artifact '%s' is not under directory expected...". Interestingly we recently hit exactly this error from the different angle: this check (before you removed it) was not applied when COPY_DYNAMIC_LIBRARIES_TO_BINARY feature is in effect. When we turned COPY_DYNAMIC_LIBRARIES_TO_BINARY to OFF we started getting this error on Windows. It seems that before you removed the check COPY_DYNAMIC_LIBRARIES_TO_BINARY must be ON for Windows otherwise this error always triggers. I wonder if your commit inadvertently fixes our scenario as well - without the check we now should be able to turn COPY_DYNAMIC_LIBRARIES_TO_BINARY to OFF on Windows. What do you think?