[apple] fix issues compiling C in objc_library for watchos/armv7k #14367
Conversation
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
keith
approved these changes
Dec 2, 2021
|
@oquenchil can you review |
9 tasks
|
Thanks for the fix! I'll import and cherrypick this shortly. |
Wyverald
pushed a commit
that referenced
this pull request
Dec 7, 2021
Reproducible example here: https://github.com/dflems/bazel-repro-armv7k. This was tested against 5.0.0 rc2 and latest master and fails on both. The build succeeds after this fix is applied. Basically, if you have any non-objc files (like C sources) in `objc_library` rules, they'll get compiled for the wrong architecture when targeting watchOS/armv7k. The target triplet for the `watchos_armv7k` CPU was set to `armv7-apple-watchos` instead of `armv7k-apple-watchos` (which is what Xcode sets when compiling/linking for this architecture). It's been like this for a few years, but I think this has always been wrong. Before the recent starlark rewrite of the objc rules, it appears that all of the sources (objc or not) were compiled with the `-arch armv7k` arguments applied. After the rewrite, objc still gets compiled this way but C files in the same library get the target triplet from the crosstool, which is incorrect. Then when `libtool` creates the archive, the object files are filtered out because they don't match `-arch_only armv7k`. If approved, I think this should be cherry-picked into the 5.0 release. Closes #14367. PiperOrigin-RevId: 414693641
Bencodes
pushed a commit
to Bencodes/bazel
that referenced
this pull request
Jan 10, 2022
Reproducible example here: https://github.com/dflems/bazel-repro-armv7k. This was tested against 5.0.0 rc2 and latest master and fails on both. The build succeeds after this fix is applied. Basically, if you have any non-objc files (like C sources) in `objc_library` rules, they'll get compiled for the wrong architecture when targeting watchOS/armv7k. The target triplet for the `watchos_armv7k` CPU was set to `armv7-apple-watchos` instead of `armv7k-apple-watchos` (which is what Xcode sets when compiling/linking for this architecture). It's been like this for a few years, but I think this has always been wrong. Before the recent starlark rewrite of the objc rules, it appears that all of the sources (objc or not) were compiled with the `-arch armv7k` arguments applied. After the rewrite, objc still gets compiled this way but C files in the same library get the target triplet from the crosstool, which is incorrect. Then when `libtool` creates the archive, the object files are filtered out because they don't match `-arch_only armv7k`. If approved, I think this should be cherry-picked into the 5.0 release. Closes bazelbuild#14367. PiperOrigin-RevId: 414693641
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reproducible example here: https://github.com/dflems/bazel-repro/tree/master/watch-armv7k. This was tested against 5.0.0 rc2 and latest master and fails on both. The build succeeds after this fix is applied.
Basically, if you have any non-objc files (like C sources) in
objc_libraryrules, they'll get compiled for the wrong architecture when targeting watchOS/armv7k.The target triplet for the
watchos_armv7kCPU was set toarmv7-apple-watchosinstead ofarmv7k-apple-watchos(which is what Xcode sets when compiling/linking for this architecture). It's been like this for a few years, but I think this has always been wrong.Before the recent starlark rewrite of the objc rules, it appears that all of the sources (objc or not) were compiled with the
-arch armv7karguments applied. After the rewrite, objc still gets compiled this way but C files in the same library get the target triplet from the crosstool, which is incorrect. Then whenlibtoolcreates the archive, the object files are filtered out because they don't match-arch_only armv7k.If approved, I think this should be cherry-picked into the 5.0 release.