react-native-purchases: Undefined symbol: _swift_stdlib_isStackAllocationSafe

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)
  1. Environment
    1. Platform: MacOS
    2. SDK version: 4.5.2
    3. OS version: macOS Monterey
    4. Xcode version: 13.3
    5. React Native version: 0.64.0
    6. SDK installation (CocoaPods + version or manual): cocoapods
    7. 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)

Most upvoted comments

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_paths function 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:

  post_install do |installer|
    react_native_post_install(installer)
    fix_library_search_paths(installer)
  end
end

def fix_library_search_paths(installer)
  def fix_config(config)
    lib_search_paths = config.build_settings["LIBRARY_SEARCH_PATHS"]
    if lib_search_paths
      if lib_search_paths.include?("$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)") || lib_search_paths.include?("\"$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)\"")
        # $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) causes problem with Xcode 12.5 + arm64 (Apple M1)
        # since the libraries there are only built for x86_64 and i386.
        lib_search_paths.delete("$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)")
        lib_search_paths.delete("\"$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)\"")
        if !(lib_search_paths.include?("$(SDKROOT)/usr/lib/swift") || lib_search_paths.include?("\"$(SDKROOT)/usr/lib/swift\""))
          # however, $(SDKROOT)/usr/lib/swift is required, at least if user is not running CocoaPods 1.11
          lib_search_paths.insert(0, "$(SDKROOT)/usr/lib/swift")
        end
      end
    end
  end

  projects = installer.aggregate_targets
    .map{ |t| t.user_project }
    .uniq{ |p| p.path }
    .push(installer.pods_project)

  projects.each do |project|
    project.build_configurations.each do |config|
      fix_config(config)
    end
    project.native_targets.each do |target|
      target.build_configurations.each do |config|
        fix_config(config)
      end
    end
    project.save()
  end
end

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):

Screen Shot 2022-03-17 at 7 00 28 PM

So in summary, I’d say there are three options:

  • Upgrade to 0.67
  • Add that fix_library_search_paths post install function
  • Change the Library Search Paths in the project manually. Removing "$(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.

Change the Library Search Paths in the project manually. Removing "$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)" and adding "$(SDKROOT)/usr/lib/swift"

this fixed it for me 😃 Thank you so much

Change the Library Search Paths in the project manually. Removing "$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)" and adding "$(SDKROOT)/usr/lib/swift"

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.