-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NPE when using manually created CcInfo with dynamic_library #11167
Comments
cc @katre per Jay's remark |
When using |
Okay, took a look. The problem here (as the stack trace shows) is in LibrariesToLinkCollector, line 247:
In your case, the
And the expected
So, short answer, this fails to consider libraries in output dirs based on transitions to non-target configurations. The check for a valid soDir needs to be updated. |
I don't work in this level of the CC code, and @hlopko is no longer part of the Bazel team, so re-assigning to @oquenchil to triage and fix. |
Thank you for the quick response @katre! Sad this isn't a bug in my code though :( |
I will update the check to give a proper error instead of a crash. |
I was wondering, could it break |
I believe you can trigger the code path causing the error with a .so from a cc_import. The problem that wanted to be avoided initially with that check was not to have the same .so be linked more than once if it showed up in the graph having been built in different configurations. Unfortunately, it's more restrictive than it should be because it simply doesn't allow an so from a different config. I introduced a class during a refactoring that added the label of the target to a wrapper around LibraryToLink: That was an incompatible change because people were allowed to create these objects from Starlark. Once everyone is using LinkerInput with a non-null label, I think we can re-write this check and linking a library from a different configuration should work. Once this flag is flipped: We can look at this issue again. |
If it does trigger the crash with |
> 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 bazelbuild#11727 Fixes bazelbuild#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 bazelbuild#11721. PiperOrigin-RevId: 322563028
Description of the problem / feature request:
NPE when using a manually created
CcInfo
and usingdynamic_library
.Creating a
CcInfo
with the following snippet:Bazel 3.0.0 will NPE when using the shared_library property:
The same happens with trying to merge this
CcInfo
with other viacc_common.merge_cc_infos
:Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Checkout bazel-contrib/rules_go#2445, and run:
What operating system are you running Bazel on?
macOS
What's the output of
bazel info release
?Have you found anything relevant by searching the web?
No
Any other information, logs, or outputs that you want to share?
See bazel-contrib/rules_go#2445
The text was updated successfully, but these errors were encountered: