search

mixpanel / mixpanel-react-native

Official React Native Tracking Library for Mixpanel Analytics
https://mixpanel.com
Apache License 2.0
108 stars 48 forks source link

App build fails on iOS 14.5 #43

Closed cigaciga closed 3 years ago

cigaciga commented 3 years ago

I'm having an issue after upgrading to Xcode 12.5 and iOS 14.5, build is failing with error:

Undefined symbols for architecture x86_64: "Swift._ArrayBuffer._copyContents(initializing: Swift.UnsafeMutableBufferPointer) -> (Swift.IndexingIterator<Swift._ArrayBuffer>, Swift.Int)", referenced from: generic specialization <serialized, Swift._ArrayBuffer> of Swift._copyCollectionToContiguousArray(A) -> Swift.ContiguousArray<A.Element> in libMixpanel-swift.a(AutomaticProperties.o) ld: symbol(s) not found for architecture x86_64

taschik commented 3 years ago

We discovered the same here, too.

AndreasGS commented 3 years ago

+1. Disabled mixpanel until it's fixed

VincentQuillien commented 3 years ago

same here

zihejia commented 3 years ago

Sorry guys! We are looking into this now.

mavarazy commented 3 years ago

+1

kkelley-leftbrain commented 3 years ago

Hey all - there appears to be some workarounds for 0.64 and at least in my case, 0.63.3 found in the thread mentioned above. My solution was pulled from a lot of folks across a few issues, found here.

@zihejia not sure if this is potentially the solution here, as a lot of the pain is coming from the Big-Sur automatic updates jacking with XCode and a cascading number of libraries coupled with it. Always appreciate the work you guys are doing, thank you for the support

Cheers

zihejia commented 3 years ago

Thanks @kkelley-leftbrain and everyone who brought this up and provided the valuable information. Here is the workaround based on the threads. Tested in Xcode 12.5 and RN 0.64

zihejia commented 3 years ago

Feel free to reopen if the above solution doesn't work, or contact our support if you need to continue the conversation for any critical issues.

checklist commented 3 years ago

Thanks @kkelley-leftbrain and everyone who brought this up and provided the valuable information. Here is the workaround based on the threads. Tested in Xcode 12.5 and RN 0.64

  • open the iOS project/workspace project file
  • go to the Build Settings of your project, search for Library Search Paths
  • remove $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) image
  • add an empty swift file to your iOS target and create the Bridging Header when prompt image

Guys - this has been open since April. It is now August. Shouldn't have this been handled without this extra work?

Thanks in advance.

jckw commented 3 years ago

Should this issue be closed? There might be a work around but this doesn't feel fully solved. Do we know why the workaround works (and what does removing the library path do?)?

IdrisHanafi commented 3 years ago

Using XCode 12.5.1 and RN 0.63.4. @zihejia

Couldn't find the $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) in my Library Search Paths. But I did try adding the bridging header but no luck (same error). Would love to see an updated status on this, thanks! :)

ekram21 commented 3 years ago

I Couldn't find the $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) in my Library Search Paths either. If this doesnt get resolved soon I may have to look for alternative to mixpanel.

Any ETA when will be resolved? @zihejia

zihejia commented 3 years ago

hi @ekram21 @IdrisHanafi , would you like to check out the latest issue from RN about this? Unfortunately, this issue has still not been fully resolved and a workaround is still needed. It is not specific to Mixpanel but more related to RN with Xcode.

mikehardy commented 3 years ago

Coming over here from the related react-native issue, we've worked on this for the next release (0.66) of react-native and have implemented the required workarounds in a general way. This affects everyone using react-native so if you can please spread the word to other developers in any other repos you work in to help them out, pointing that related issue and encouraging them to examine the Podfile addition that helps people https://react-native-community.github.io/upgrade-helper/?from=0.65.1&to=0.66.0-rc.4 (check the Podfile workaround line that was added)

ololoepepe commented 3 years ago

@zihejia So you say this is RN and Xcode issue, then how could it be that my project compiled fine with the same RN and Xcode versions until installing Mixpanel? The issue still exists and there is no workaround (at least for Xcode 12.5.1). The methods posted above does not work (at least for my case), as I do not have $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) path nor does the fix from https://github.com/facebook/react-native/issues/31480 help.

mikehardy commented 3 years ago

Perhaps mixpanel is the first Swift code you've ingested @ololoepepe ? There should be no problems like this on react-native 0.66 (released now).

ololoepepe commented 3 years ago

@mikehardy Well, I have more than 60 native modules and some code in AppDelegate.m (if that counts). Surely I have faced some issues from time to time, but none was without a fix/workaround and developers saying "this is not our fault, we will not do anything to fix it". As for upgrading RN version (mine is 0.64.2), it is hard or even impossible to just upgrade without breaking some package. I know one should upgrade from time to time, but doing it too often is a pain and waste of empolyer's money (especially when some packages break and one have to fix them).

ololoepepe commented 3 years ago

RN 0.66 gives the same error, by the way.

mikehardy commented 3 years ago

I hear you. It's really not easy. Are you certain that on the upgrade to 66 you put the compile workaround function call in your podfile? Have you checked out the archs specifiers I slice in via podfile in react-native-firebase tests podfile? I don't have 60 native modules in my app but I maintain about 30 native modules and in my experience this is an xcode config issue that is out of module's control. I collaborated directly with the react-native team to add workarounds for that reason and we had no fail reports by the time we released 66

mikehardy commented 3 years ago

I have lots of caching so npx react-native-clean-project was needed in my case as well then pod reinstall and I blew away my ccache for good measure.

ololoepepe commented 3 years ago

@mikehardy

Are you certain that on the upgrade to 66 you put the compile workaround function call in your podfile?

Yes, it is there.

this is an xcode config issue that is out of module's control

Well then how do other packages maintainers avoid such issues? I understand there may be a bug in RN, or Xcode, or whatever, but the packages people use do not exist in an isolated space, they exist in the same world as those buggy tools and incorrect (incorrect for what, by the way?) configs.

Say you produce cars, but the roads are not very well and you cars can not be used on those roads. So you say: "I have made a car, and it is not my problem you can not use it on the roads". Then why even produce that car? It is useless in real world outside the factory it was produced at.

I mean, why not change something about the lib to improve it's compatibility, so it is more incorrect-configuration-tolerant? The whole history of this lib's releases consists of "fixed compiling on ios", "fixed what previous improvement have broken" and so on.

mikehardy commented 3 years ago

Just to make sure I did this:

npx react-native init MixPanelTest --version 0.66.0
cd MixPanelTest
yarn add mixpanel-react-native
cd ios && pod install && cd ..
yarn ios

it worked

Other module maintainers don't avoid the issues (they're not avoidable), (so finally) I had to work with the core to fix Xcode builds.

I'm not going to pontificate about metaphors, I don't see build errors when I apply documented workarounds (for RN < 0.66) or have a fresh RN66 app

ololoepepe commented 3 years ago

I've tried react-native-clean-project with exact same results. I have never made any extra changes to xcode/Podfile/whatever-ios-build-related after create-react-native-app my-project, so it's as common and default as possible.

And once again, as for blindly upgrading to the next version of RN, there are issues with other packages (at least appropriate react-native-reanimated release seems to be buggy and causes crashes). You may say again "this is 3rd-party persons who causes this", but wait, again, we all live the same world, and react-native-reanimated is used more often than mixpanel-react-native.

ololoepepe commented 3 years ago

At the end it may be just easier and cheaper for employer to just choose another service with better libs than spending developer's hours (and thus money) fighting with what is just broken.

mikehardy commented 3 years ago

Yep, I patched react-native-reanimated as well: https://github.com/software-mansion/react-native-reanimated/issues/2477#issuecomment-939141314 But if you stay on lower than react-native 0.66 with reanimated and gradle flavors you have a separate problem. It's just hard, all this software. I'm busy fixing things and trying to help you though. Or I was, off to real work now, cheers

ololoepepe commented 3 years ago

@mikehardy

Just to make sure I did this: it worked

mikehardy commented 3 years ago

Metaphors are inefficient ways to convey meaning. We're talking about scientific experiments with reproducible methodologies, that is, scripts here. You cannot build humans from scratch. This software and all of its dependencies may be built from scratch for a directly reproducible experiment. I did that. You can do that with your app too.

ololoepepe commented 3 years ago

For anyone who struggle with this issue: you may use react-native-mixpanel. It is deprecated, but at least it works (without requiring some mysterious right configuration).

kkelley-leftbrain commented 3 years ago

@ololoepepe I really wouldn't recommend that.

I hung out with @zihejia and company whilst they made the transition from closed beta to the public repo, and there is a trove of changes that you would be missing, in addition to operating the underlying API in a non-standard way (see: JS/HTML-esque approach when a fully supported RN version is available for you to use here).

I slogged through a nearly identical plight with the issue mentioned at the very top of the thread, and did my best to link to some other workarounds. @mikehardy has also given you quite a bit to work with here.

Generally speaking, if you're changing versions of RN, or any of your underlying library dependencies, there's going to be some friction and I recommend taking it one step at a time. Save off progress (i.e. commit) at each phase so you can go the nuclear option if things get too jacked up along the way.

If there's anything specifically you're running into, feel free to drop me a line and we can compare notes when I've got a moment.

Cheers

ololoepepe commented 3 years ago

@kkelley-leftbrain While I agree with you generally, there is just too much effort to make this lib work. For me and our company it does not worth time and money spent. I'm not an iOS pro, but I suspect some unusual native things are used by the lib, that's why it requires unusual configuration. At the very least, I suggest the devs add this to the docs, like "change that line to X", "make sure you have Y set to Z", etc. This lib is not the only available (and so is Mixpanel), so why waste our time? There is a kind of devs who loves all brand-new things and can't live without bringing that things into projects immediately. Often these things break everything (just because some time is needed to test/fix bugs/etc.). Unfortunately, that kind of devs is also very stubborn and never replaces their unusual stuff with something "good old". They love to fight their own tools and thinks others also must like it and have unlimited time to do so.

mikehardy commented 3 years ago

"unusual things" used by this module, in this case === "Swift",

That is, the next major language that will be / is used by all iOS devs

It's just that react-native was a little slow starting to adopt it, and Xcode itself has issues with it at some deep layers (like, they ship iOS Simulator SDKs without the symbols sometimes! It's crazy)

So from that perspective, this is not an unusual requirement, It is something that needs a real solution in your project and that's why I've worked so hard to try to get the required workarounds distributed out to people. At the same time it's just a real difficult area of iOS development at the moment. If other libs haven't hit it, they will.

I personally know of two widely-adopted libs that were bitten by this: the react-native-fbsdk-next and react-native-firebase.

ololoepepe commented 3 years ago

@mikehardy

react-native was a little slow starting to adopt it, and Xcode itself has issues with it at some deep layers

That's why we absolutely have to use it right now. Yep, that's what I was talking about in the previous post.

BTW react-native-firebase is used in my project from the very beginning without any issues.

mikehardy commented 3 years ago

BTW react-native-firebase is used in my project from the very beginning without any issues.

You're welcome ;-). But more seriously if you try to use the newer modules, like App Check - this will happen, right now.

evanlarkin10 commented 3 years ago

I'm experiencing this issue, and I can't find $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) in the Library Search Paths either from @zihejia answer. Is there any other resolution yet?

kkelley-leftbrain commented 3 years ago

@evanlarkin10 , I had to manually edit my project.pbxproj file manually for that step, not sure if that helps (i.e. Ctrl+F "TOOLCHAIN" within the file in an editor)

LucasGarcez commented 2 years ago

I have the same problem. The only way that works for me was to update macOS to Monterey 12.1, so update Xcode to 13.2.1. No need for other steps, install lib and pods normally. My project usereact-native 0.64.0 and mixpanel-react-native 1.3.4

zihejia commented 2 years ago

Thanks @LucasGarcez for pointing it out. Yes, for anyone who has been impacted please update Xcode to 13.2.1 as long as you can, so there is no need for any extra steps mentioned in this thread. Thanks for everyone's great input and sorry for the inconvenience, special thanks to @kkelley-leftbrain @mikehardy and @LucasGarcez !

dnlPacheco commented 2 years ago

I'm having a problem similar to this error "Undefined symbols for architecture x86_64". Build is failing with this error:

Undefined symbols for architecture x86_64:
 "_RCTRegisterModule", referenced from:
   _initialize_MixpanelReactNative in MixpanelReactNative-7b8382e86c4871ddf502e2111c31c78a0bf98ae8fe355805573d3bbbc4a2d3d1.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I tried to build in 2 different Mac's:

It's the same project using "react-native: 0.63.4" and "mixpanel-react-native": 1.3.7".

After reading this comment in this issue: https://github.com/facebook/react-native/issues/29633#issuecomment-694187116.

I changed the s.dependency to React-Core in MixpanelReactNative.podspec and the app build successfully.

ololoepepe commented 2 years ago

So finally there is an issue in this lib (incorrect dependency). Not a big surprise though.

wgley3 commented 2 years ago

I changed the s.dependency to React-Core in MixpanelReactNative.podspec and the app build successfully.

I was really having an issue with this, and this ended up being the fix. Thanks @dnlPacheco !!

princefishthrower commented 2 years ago

@dnlPacheco @wgley3 , even after doing this modification and running pod update in my ios/ folder, I'm still having troubles. Are there any other steps you may have forgot to mention here?

I'm also worried about the brittleness of this solution, won't the MixpanelReactNative.podspec file get overwritten every time we upgrade mixpanel?

@mikehardy - I see the podfile modification you mentioned, it's called __apply_Xcode_12_5_M1_post_install_workaround(installer) - does this only help M1 macs or will it also help macs in general?

BTW I am on react-native 0.67.2, so I'm not sure how I ran into this issue 😅 (my guess is that my podfile wasn't touched by past upgrade commands because we have so much custom tooling)

EDIT: It gets worse; I indeed DO have this fix line in my Podfile.... so I'm lost for now, maybe I have to do this cache cleaning...

mikehardy commented 2 years ago

the __apply_Xcode_12_5_M1_post_install_workaround(installer) workaround is more of a "12.5+ or M1" workaround, it fixes issues with both, and is modified over time in new react-native versions to only be what's currently required. You can see it's history here https://github.com/facebook/react-native/blame/main/scripts/react_native_pods.rb#L564-L591

Not sure if you need to, but If you need to patch a podspec, patch-package is your friend https://github.com/ds300/patch-package/ - it will warn you when patches don't apply or versions change so it's not that brittle as it is more "fail fast" as you update. I use it all the time personally.

paprikka commented 2 years ago

Hi there! Am I correct to think that https://github.com/mixpanel/mixpanel-react-native/pull/150 would fix the issue mentioned by @dnlPacheco ?

paprikka commented 2 years ago

I'm on RN 0.68.x, Xcode 13.4. Here's what worked:

  1. fork this repo
  2. update the podspec file with the patch mentioned in #150
  3. use the package from GH 
    // in package.json
- "mixpanel-react-native": "^1.4.2",
+ "mixpanel-react-native": "git+ssh://git@github.com/<your org name>/mixpanel-react-native.git",
  4. clean your pods and reinstall all dependencies $ yarn, then $ arch -x86_64 pod install --repo-update
  5. subscribe to the notifications for this repo, so you can drop the fork once it gets updated 🚀💰
hamzakashifCL commented 11 months ago

I am still getting this error with React Native 0.73 and Xcode 15.1