-
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
Crash when building objc_library
#13862
Comments
cc @oquenchil |
objc_library
objc_library
Can you include the target declaration that causes the crash? |
The crash was with a custom rule (from https://github.com/bazel-ios/rules_ios) that generates a header map, you can see an example with the rule source code here: https://github.com/thii/objc_library_crash, and reproduce the crash with:
|
Okay, it wasn't related to the custom rule, but seems related to the location expansion in
|
Do you still have this problem on the latest builds? EDIT: sorry it's a mistake. We still have the same error. (I'm trying to workaround this by using an old bazel + some patches.) |
Hmm, we're still seeing the same crash with 6.0.0-pre.20211025.1. |
@thii how are you able to get around this? Do you have a custom Bazel fork with the necessary apple silicon and cross tool changes? This seems like a significant issue since Bazel 5 is more or less tied to getting native apple silicon builds working (at least how it currently appears to me) |
@tinder-maxwellelliott We only have a handful of objc_library targets, so we just skip using header maps for now to work around this. If you just want to support building for the simulator on Apple Silicon, you can try to patch Bazel 4.2.1 with the necessary changes: |
@oquenchil This seems to affect a lot of users especially who need to build mixed Obj-C & Swift modules. What do you think about adding the native implementation of Obj-C rules back and adding a flag to allow switching between the native and the Starlark implementation of them until the Starlark one becomes stable? |
@Wyverald I think this would count as a 5.0 release blocker. |
Is #14173 the same? |
Yeah it looks like #14173 is the same problem 👍 . cc @amberdixon who I believe has context on an in-progress fix / added test coverage to prevent this from regressing |
@oquenchil also has a fix in flight already. Should be submitted tomorrow |
Can we re-open this until it's in the 5.0 rc branch? |
Fixes #13862 RELNOTES:none PiperOrigin-RevId: 409139722
Cherrypicked. (Tried out GitHub desktop, hope it didn't backfire o,o) |
*** Reason for rollback *** broke stuff *** Original change description *** Do location expansion in copts of objc_library Fixes #13862 RELNOTES:none PiperOrigin-RevId: 409910075
The fix was reverted. Can we re-open this? |
*** Reason for rollback *** broke stuff *** Original change description *** Do location expansion in copts of objc_library Fixes #13862 RELNOTES:none PiperOrigin-RevId: 409910075
Roll forward with placing every TransitiveInfoCollection in a set so that duplicate entries are removed. Test has been modified to exercise the duplicate case. Fixes #13862 RELNOTES:none PiperOrigin-RevId: 410209862
Description of the problem / feature request:
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I'll submit an example later.
What operating system are you running Bazel on?
macOS
What's the output of
bazel info release
?I used
last_green
Bazel.The text was updated successfully, but these errors were encountered: