-
Notifications
You must be signed in to change notification settings - Fork 24.5k
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
Feat/ios m1 improvements #32296
Feat/ios m1 improvements #32296
Conversation
See facebook@a1c445a#commitcomment-57240925 This is producing a message that it will be deprecated, so we should just remove that.
Summary: Since Apple released its own silicon M1, an ARM64, the react-native build is broken or at least not as effective as it should. This PR stops excluding `arm64` simulator (this is not needed on the M1 neither on Intel devices) and removes the problematic `$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)` from `LIBRARY_SEARCH_PATHS`, since on Xcode 12.5 and 13.0 this folder contains only `i386/x86_64` binaries and will fail compilation. Instead this PR forces `$(SDKROOT)/usr/lib/swift` while it removes the incorrect directory. Ideally we could just remove `LIBRARY_SEARCH_PATHS` altogether if `$(inherited)` and `$(SDKROOT)/usr/lib/swift` were the only entries, but it would require us a **newer CocoaPods**, since that was fixed with `1.11` (see CocoaPods/CocoaPods@6985cbf). Since we don't enforce that, lets keep the `$(SDKROOT)/usr/lib/swift` and call it done. Last but not least, deprecate the `__apply_Xcode_12_5_M1_post_install_workaround()` as it's not needed anymore, at least with recent versions of the dependencies, no patching is required with RCT-Folly, neither we need to force `IPHONEOS_DEPLOYMENT_TARGET=11.0` ## Changelog [iOS] [Fixed] - Xcode 12.5+ build of iPhone Simulator on Apple M1 [iOS] [Changed] - Do not exclude the arm64 iphonesimulator [iOS] [Deprecated] - __apply_Xcode_12_5_M1_post_install_workaround() Pull Request resolved: #32284 Test Plan: * Build `packages/rn-tester` on M1 and see it still works properly * Run `pod install` on x86_64 and arm64 (m1) and see the `project.pbxproj` is not changed ## References: * Closes #31480 * The initial fix ac4ddec * Upgrading CocoaPods to 1.11 would bring us CocoaPods/CocoaPods@6985cbf and we could avoid adding `$(SDKROOT)/usr/lib/swift` ourselves Reviewed By: lunaleaps Differential Revision: D31248460 Pulled By: fkgozali fbshipit-source-id: 5a0d69593e889e296a2ba2e7b4387ecbd56fc08d
scripts/react_native_pods.rb
Outdated
@@ -16,6 +16,11 @@ def use_react_native! (options={}) | |||
# Include Hermes dependencies | |||
hermes_enabled = options[:hermes_enabled] ||= false | |||
|
|||
# Running `pod install` from inside Rosetta2 is a bad sign | |||
if `/usr/sbin/sysctl -n hw.optional.arm64 2>&1`.to_i == 1 && !RUBY_PLATFORM.start_with?('arm64') | |||
Pod::UI.warn 'Do not use Rosetta2 with "pod install"' |
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.
what should people do instead? Maybe add a 2nd sentence pointing to a resource or list out the mitigation for them
Maybe also add comment that this may happen when using Apple Silicon machines?
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.
Ok, will reword the message
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.
If there's no existing resource/doc about this, you can explain them in comment (in a paragraph form). And/or pull this out to a helper function so you can isolate the documentation.
Anyway your call :)
I'll merge this by EOD US time (pending comment clarification mentioned above) |
Base commit: dd99475 |
Running `pod install` from inside Rosetta2 can lead to problems, try to avoid doing that by hinting users from use_react_native!() function. $ arch -x86_64 pod install Building RNTester with Fabric enabled. Building RNTester with Fabric enabled. Building RNTester with Fabric enabled. Analyzing dependencies Downloading dependencies Generating Pods project Integrating client project Pod installation complete! There are 63 dependencies from the Podfile and 50 total pods installed. [!] Do not use "pod install" from inside Rosetta2 (x86_64 emulation on arm64). [!] - Emulated x86_64 is slower than native arm64 [!] - May result in mixed architectures in rubygems (eg: ffi_c.bundle files may be x86_64 with an arm64 interpreter) [!] Run "env /usr/bin/arch -arm64 /bin/bash --login" then try again.
8d49ab3
to
2175216
Compare
@fkgozali improved the messaging. Also, inside our company we noticed that even when running outside of Rosetta2, depending on the previous "mess", the if `/usr/sbin/sysctl -n hw.optional.arm64 2>&1`.to_i == 1
if !RUBY_PLATFORM.start_with?('arm64')
Pod::UI.warn 'Do not use "pod install" from inside Rosetta2 (x86_64 emulation on arm64).'
Pod::UI.warn ' - Emulated x86_64 is slower than native arm64'
Pod::UI.warn ' - May result in mixed architectures in rubygems (eg: ffi_c.bundle files may be x86_64 with an arm64 interpreter)'
Pod::UI.warn 'Run "env /usr/bin/arch -arm64 /bin/bash --login" then try again.'
else
Pod::UI.info 'If you get crashes related to ffi (eg: ffi_c.bundle), it may be related to mixed "bundle install" from different architectures (x86_64, arm64), please cleanup and try again. Its is NOT a bug with react-native'
end
end However I did not add that as it would be disturbing to most people that did not have the mess... but if you do have some FAQ with:
|
build failures looks unrelated, but would be nice to confirm |
Yeah test failure seems unrelated. Let's proceed. |
@fkgozali has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
Summary
Changelog
[iOS] [Fixed] - Removed __apply_Xcode_12_5_M1_post_install_workaround
[iOS] [Changed] - Warn if Rosetta2 is being used (x86_64 on arm64)
Test Plan
Build on macOS Apple devices without any warnings during
pod install