Firebase 6.15.1 - xCode Error - Undefined symbols for architecture arm64

[npicouet]

Please fill in the following fields:

Unity editor version: 2019.3.13f1 Firebase Unity SDK version: 6.15.1 Source you installed the SDK: Package Manager Firebase plugins in use: Every Single One! Additional SDKs you are using: Facebook, Google Sign In, Apple Sign In Platform you are using the Unity editor on: Mac Platform you are targeting: iOS and Android Scripting Runtime: IL2CPP

Please describe the issue here:

xCode Build Error with latest Firebase Unity SDK:

Undefined symbols for architecture arm64:
  "firebase::firestore::api::Firestore::Dispose()", referenced from:
      firebase::firestore::FirestoreInternal::~FirestoreInternal() in libFirebaseCppFirestore.a(firestore_ios_eec52dfa6e1434eb3ea69ba309362c0c.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

All I did was update Firebase in Package Manager to 6.15.1, and try to run an xCode build. Received this error.

Please answer the following, if applicable:

Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)? Haven't tried.

What's the issue repro rate? (eg 100%, 1/5 etc) 100%

[npicouet]

Okay, I found the solution. This should probably be updated or hotfixed, since xCode 100% doesn't work in 6.15.1.

The ios dependencies are using an outdated ios sdk version that doesn't contain a method being called by Firebase.

The solution is to go into all your "dependency.xml" files and change the dependency version from "6.24.0" to "6.27.0".

[vzlomvl]

I have the same issue. I am able to reproduce even with an empty project (just with Firestore, Auth 6.15.1 dependencies)

[Blazerker]

Same Issue.

ld: warning: arm64 function not 4-byte aligned: _unwind_tester from /Users/peter/Dropbox/Projects/Blokaspaai 2/App 2020/iOS/Blokaspaai/Libraries/libiPhone-lib.a(unwind_test_arm64.o) Undefined symbols for architecture arm64: "firebase::firestore::api::Firestore::Dispose()", referenced from: firebase::firestore::FirestoreInternal::~FirestoreInternal() in libFirebaseCppFirestore.a(firestore_ios_eec52dfa6e1434eb3ea69ba309362c0c.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

[gindemit]

Okay, I found the solution. This should probably be updated or hotfixed, since xCode 100% doesn't work in 6.15.1.

The ios dependencies are using an outdated ios sdk version that doesn't contain a method being called by Firebase.

The solution is to go into all your "dependency.xml" files and change the dependency version from "6.24.0" to "6.27.0".

Can you please provide the path to the dependency.xml files? I can find it only in PackageCache\com.google.firebase.analytics@6.15.1\Firebase\Editor\ folder.

[gindemit]

I am wonder how the test pipeline looks for Firebase team when new version of Firebase plugin for Unity is released. Not to catch linker errors (build errors) before release is a sign that the test process does not exist. This brings me to expect worst when I update the plugins version.

[npicouet]

Okay, I found the solution. This should probably be updated or hotfixed, since xCode 100% doesn't work in 6.15.1. The ios dependencies are using an outdated ios sdk version that doesn't contain a method being called by Firebase. The solution is to go into all your "dependency.xml" files and change the dependency version from "6.24.0" to "6.27.0".

Can you please provide the path to the dependency.xml files? I can find it only in PackageCache\com.google.firebase.analytics@6.15.1\Firebase\Editor\ folder.

@khindemit I'm not sure the exact paths. I just searched "dependencies" in my Unity project, and changed the search parameter to "In Packages". That should find all the files you need to edit within your PackageCache.

[pitrees]

I found the dependencies files @npicouet mentioned, Assets/Firebase/Editor/AppDependencies.xml Assets/Firebase/Editor/AuthDependencies.xml Assets/Firebase/Editor/FirestoreDependencies.xml Assets/Firebase/Editor/<...>Dependencies.xml

Change the version="6.24.0" into "6.27.0" at between

[Thaina]

Are there a way to fix this for UPM?

[AnnMic]

Is there anyway of avoiding that the package cache is reseting the dependency files back to "6.24.0".

The moment I open Unity I get the error: "The package cache was invalidated and rebuilt because the following immutable asset(s) were unexpectedly altered:..." and it resets the dependency files.

[npicouet]

Are there a way to fix this for UPM?

If you are talking about Unity Package Manager, that is what I'm using, and the same fix applies. You just have to look in your Library/PackageCaches, and change the dependency version before you build.

Its not ideal, we need a hotfix for this.

Is there anyway of avoiding that the package cache is reseting the dependency files back to "6.24.0".

The moment I open Unity I get the error: "The package cache was invalidated and rebuilt because the following immutable asset(s) were unexpectedly altered:..." and it resets the dependency files.

Not that I know of, I've been doing it manually every time for now. Annoying!

[Thaina]

@npicouet In 2020 the packagecache hack is not possible anymore. Unity just force reset every package from UPM that was changed locally (I don't even know why they try to do this). So that's why I am asking for real fix with UPM

[Jack37]

If editing (for example) Packages/Cloud Firestore for Firebase/Firebase/Editor/FirestoreDependencies.xml doesn't work for you, you can update dependencies version after the Xcode project is created.

Open the Podfile inside your Xcode project folder, and you should see all of your dependencies listed here. The file can look like this:

source 'https://github.com/CocoaPods/Specs.git'
source 'https://github.com/CocoaPods/Specs'
platform :ios, '10.0'

target 'UnityFramework' do
  pod 'Firebase/Core', '6.24.0'
  pod 'Firebase/Firestore', '6.24.0'
  pod 'Firebase/Functions', '6.24.0'
end

Just change the 6.24.0 to 6.27.0 for every Firebase related pod.

Next, run the pod update command from the Terminal, and it should work.

[vzlomvl]

@stewartmiles @chkuang-g @a-maurice Hi Google Team. Looks like the last release of Firebase Firestore(6.15.1) has a critical bug. Are you planning to fix it anytime soon? Thanks.

[jonsimantov]

Hi,

We have a fix for this and the updated SDK will be released as soon as possible. Thanks for your patience!

Jon

[Thaina]

@jonsimantov What timescale of this soon? Yearly soon, monthly soon, or weekly soon?

[alexames]

Hi everyone, the release with the fix for this is out now.

@Thaina Sorry about not being able to provide a timeline, I know this has been a frustration of yours for a while. It's frustrating for me too because it legitimately stresses me out to know that people are waiting on a release and I can't really predict how long it will take to put together. To give some insight into this, the process can take a while for a number of reasons: Once a fix is identified, tested, and checked in internally (which can take a hard to predict amount of time), the process of putting together a release build is very time consuming. Because we support a dozen libraries across several versions of Unity that need to build on at least 5 different platforms we have a large matrix of unit and integration tests that need to run. Most of these are completely automated at this point, though not all of them can be due to the limitations on some platforms.

Once tests have passed there are additional steps to get everything packaged and uploaded, and these packaging steps take a nontrivial amount of time too. If there are problems found in the build for whatever reason a lot of this process has to be re-run, and if the issue is discovered too late in the evening that can easily push the release the next day. And as you can see by this bug here, there are some gaps in our suite of tests that we are working to fill so that we don't repeat these mistakes. All this to say - this process is frustrating to us too. One of our top priorities right now is to clean this process up so that builds can be done much more rapidly with much less manual intervention. We want to be able to hit a single button and reliably produce a working build. We aren't there yet, but we are actively putting a lot of resources to getting to that point.

I'm sorry again for the frustration this has caused and I just wanted to make it clear we're aware of how painful this is for everyone involved and are taking steps to address it. My hope is that going forward releases will be much less stressful and iteration times much lower.

[Thaina]

@alexames My point is, it was historical reason that your soon has no deliberate timescale over it

Your whole process is understandable and acceptable, but for any fix to be launch, for all of that process I assume it should not take more than 5 days, and might be 10 days for any problem occur, and on average should be 3 days, like this problem, which is under expectation of soon of normal people

But problem is you word soon is not consistence

You have used the word soon on firestore unity sdk itself since 3 years ago, it take whole year and a half for it to be released

And soon again on firestore bug that constantly crash client, this is seriously a critical bug, and you use the word soon for the critical bug that only fix after 3 whole months of reporting

We all developer here. We know process of development is unpredictable time. But there are expectable range of time for each and every issue when you start and finish it Problem is, we are not on your team, we don't know the dependency or complication of each issue at all because you don't open source all of this

But one thing I am sure you could tell us is timescale You see I use the word timescale right? Not exact date and time itself, as I has been describe we should know vague prediction of process Just as you have told me, even without any issue, just try to build it take 1-3 days and 1 on average, and that was understandable and for me it was acceptable We then could predict that if there was some issue that would take 2 days, the whole process might be 3 - 7 days, that was acceptable enough as soon

But we don't actually know which issue is just that. You same word soon can have variety of timescale attached on it up to the issue and dependency. But when you tell us you only use same soon words without actual timescale

This is my point. Every issue is soon in your perspective because you know the timescale of it. SDK is soon for the next year. Crash bug is soon in a month. And this issue is soon in under a week

But we here don't know about that, we know only same soon words and we expect it to be the same unit, a week soon unit

In summary. there are 2 ways I think it will lift our frustration

1 - Attach timescale on fix, you can say vaguely range like 5-15 days or 1-4 months. And we would be able to plan for the worst case

2 - Opensource all of these thing you talk about

[hdemircioglu]

Hi, I upgraded to 6.15.2, but still has the same problem. When I checked Library/PackageCache dependencies are pointing 6.24.0 in this version too. Can you please check the fix?

[Thaina]

@hdemircioglu I would suggest you should close unity, delete Library and Temp folder and Packages\packages-lock.json, and reopen project to clean import everything first

[alexames]

@Thaina Thanks for your feedback. I'll try to be better about giving a timescale when talking about fixes. Generally, if we say something is "soon" or "asap" or some variation of that, it means it will be in the next release that comes out, and those can range from the next day to up to two weeks, depending on circumstances. More than once we've thought we had a build ready and then at the 11th hour someone realized the fix was incomplete for one reason or another. Anything that's not on deck to be in the next release is more nebulous, even to us, and it's really hard to put down a meaningful timescale.

Open sourcing everything is the task we're working toward right now. It's a nontrivial task because google's internal build systems and testing infrastructure are very different than what is available externally. Once we've fully migrated our work will be done in the open which should simplify things for everyone.

@hdemircioglu I agree with Thaina here, try doing a clean import - if you still have problems open a new issue and we can look at it there.