react-native-purchases: Undefined symbol: _swift_stdlib_isStackAllocationSafe
- [X ] I have updated Purchases SDK to the latest version
- [ X] I have read the Contribution Guidelines
- [ X] I have searched the Community
- [ X] I have read docs.revenuecat.com
- [ X] I have searched for existing Github issues
Describe the bug I m trying to archive react native project and I m getting the error as define in the subject “Undefined symbol: _swift_stdlib_isStackAllocationSafe”
Undefined symbols for architecture arm64:
"_swift_stdlib_isStackAllocationSafe", referenced from:
function signature specialization <Arg[1] = Owned To Guaranteed> of function signature specialization <Arg[0] = [Closure Propagated : closure #1 (__C.SKProduct) -> Swift.Bool in closure #2 (Swift.Set<__C.SKProduct>) -> () in PurchasesCoreSwift.IntroEligibilityCalculator.checkTrialOrIntroductoryPriceEligibility(with: Foundation.Data, productIdentifiers: Swift.Set<Swift.String>, completion: (Swift.Dictionary<Swift.String, __C.NSNumber>, Swift.Optional<Swift.Error>) -> ()) -> (), Argument Types : [Swift.Set<Swift.String>]> of generic specialization <__C.SKProduct> of Swift._NativeSet.filter((A) throws -> Swift.Bool) throws -> Swift._NativeSet<A> in libPurchasesCoreSwift.a(IntroEligibilityCalculator.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
- Environment
- Platform: MacOS
- SDK version: 4.5.2
- OS version: macOS Monterey
- Xcode version: 13.3
- React Native version: 0.64.0
- SDK installation (CocoaPods + version or manual): cocoapods
- How widespread is the issue. Can not make a build for the store
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 3
- Comments: 15 (6 by maintainers)
I think I figured it out, I am going to try my best to explain here what I found out:
So I managed to reproduce it with a new 0.64 project. The project gives Swift related issues even before adding
react-native-purchases. Looks like it’s due to the fact that I use an M1 laptop. Some of those issues went away when doing what’s suggested in this SO answer. But I still couldn’t archive after adding react-native-purchases…Then I tried with a new React Native 0.67 project and to my surprise, there were no Swift related issues, and the project would archive fine even after adding react-native-purchases.
So first option for you would be to try to upgrade to 0.67 and see if it gets fixed. I understand that’s not always feasible so I looked at what changed between 0.64 and 0.67 and I found this PR https://github.com/facebook/react-native/commit/a1c445a39c580037ada4a5d194a0d2daef15a25a.
It looks like they changed the library search paths for swift. They actually have added a new
fix_library_search_pathsfunction that is ran on post_install to the podfile that gets created when creating a new project. I tried adding it to the podfile of a new 0.64 RN project and it fixed the issues:Alternatively you can change your xcode project configuration and change the Library Search Paths in the Build Settings to match the following (which is the same config for a 0.67 project):
So in summary, I’d say there are three options:
fix_library_search_pathspost install function"$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)"and adding"$(SDKROOT)/usr/lib/swift"Let me know if these doesn’t fix it and I will look into it further
@vegaro thank you for the quick fix. This worked for me too.
this fixed it for me 😃 Thank you so much
For those people coming to this issue, but frustrating because they don’t see any search path mentioned above in their Xcode Build Settings:
Please still try the post install script by @vegaro. – We had this problem with a client project, and were super frustrated because this is the only issue you can find regarding this error in Xcode. We tried for 2 days to find any reference to any search path like the above mentioned. Finally I tried to include the post install script today, and it fixed the bug!.
Thanks guys!
@vegaro Thank you so much! I had the same issue and changing the Library Search Paths fixed it for me. There’s no way I would have figured this out on my own, but luckily a (notably incorrect) stack-overflow answer cited this thread as a source.