iOS Undefined symbols architecture with latest update

[marcanw]

Compiling from Animate (AIR 50.2.3.1) on Windows for iOS get this error since I updated GooglePlayServices:

[marchbold]

Looks like we need to get Harman to update the stubs packaged with the AIR SDK again. I'll look into it.

In the meantime either use macOS to package your app or revert to the previous version.

[marchbold]

Which extensions are you using that is causing this error btw?

[marcanw]

Looks like we need to get Harman to update the stubs packaged with the AIR SDK again. I'll look into it.

In the meantime either use macOS to package your app or revert to the previous version.

I reverted back. Can I update the other ane?

[marcanw]

Which extensions are you using that is causing this error btw? I would say Inapp-Billing, according to the errors in the screen of the original post.

[marchbold]

I believe that is actually the core google firebase dependency in the error, so likely one of the extensions that depend on that.

The others you listed should be okay to update for ios, as long as you aren't using the FCM variant of push notifications.

[marcanw]

I believe that is actually the core google firebase dependency in the error, so likely one of the extensions that depend on that.

The others you listed should be okay to update for ios, as long as you aren't using the FCM variant of push notifications.

I use the FCM version. So I better avoid to update till there is a solution. I ,just updated AndroidSupport. Is it fine?

[marchbold]

I would use the older versions of the androidx libs as well if you are trying to keep the same versions on android

[marcanw]

Hello @marchbold Do you know when I will have a solution for this?

[marchbold]

Hi, I have been discussing potential solutions for this with the Harman team. The main issue is that the Apple opensource compiler for iOS apps that AIR uses hasn't been updated by Apple in a while and has fallen behind the features available in Xcode. So AIR is facing an issue with packaging iOS apps on Windows that use recent features in iOS or libraries that have been packaged with the latest build tools.

As there seems to be developers who don't want to or can't use macOS, I was wondering what you all would think of a hosted packaging solution for developers on Windows where a host provided by Harman would package your application for iOS and provide the ipa as an alternative. There would obviously be a cost involved (potentially part of the AIR license), but this would allow you to continue developing iOS applications on Windows.

Would love to hear your thoughts on this idea?

(Note this doesn't affect developers using macOS for iOS development)

[sjabberwocky]

I just bought a Mac Mini 2023 for iOS build packaging, but an alternative option would be nice.

[ajwfrost]

Well, there's some more information about the cause of all this, from the LLVM project: https://github.com/llvm/llvm-project/issues/56034

I'd just looked at the symbols exported by a framework with/without this flag, and there are zero differences other than those symbols being there! But of course, within the executable code, these symbols will be called in order to call each of the selectors...

So, it may feasibly be possible to build the "latest" Apple linker on Windows, and merge in the changes that LLVM have made, and then have this support these newly built libraries. But building the Apple linker on Windows was proving to be very complex already..

The alternative option -> providing a service whereby ADT would upload the object files to an online service, backed by a macOS computer that just does the linking -> might actually be simpler! but perhaps not quicker. And scalability may be an issue (and service availability, given how often our macs reboot themselves!)

[Ender22]

I'm a bit confused because I am packaging on mac with intelliJ but the latest com.google.firebase.core.ane ANE version is also giving me the same errors.

Does the latest require an update to XCode or something? I'm using a bit of an older xcode...

[sjabberwocky]

@Ender22 I also found that the latest update of Firebase does not compile and previous crush app on launch on iOS 12.5.5.

[marchbold]

@Ender22 Yes you need to update the compiler on macOS, easiest done by updating Xcode.

@sjabberwocky I'll follow up on the crash in the Firebase repo.

[Ender22]

Is it possible to update the compiler without updating xcode? I had a lot of trouble packaging on mac before, and right now it's in a 'if it isn't broke don't fix it' state.

I've downloaded xcode13 but can't install it without updating MacOS first. Could I like, just replace the path to the compiler to the new xcode13 one maybe?

If it doesn't work like that and would be a big hassle then I'll just bite the bullet and update the OS and xcode, but thought I'd ask first.

[ajwfrost]

We've tried things like that before (there's a Developer/Toolchains folder in Xcode, iirc) and it worked to a certain extent but there may then be other issues you find with the compiler features, expected header files, and all sorts... it can get messy. So it could be worth trying, but there may be challenges... Apple tend to expect everyone updates all the time to the latest of everything...

[Ender22]

Understood, @marchbold what is the lowest xcode version that works with this ane? Apparently, my Mac is too old to install Ventura, so the best I can do is Monterey which only supports XCode 13.4 it seems. Also curious if I don't update this one ANE, which other ANE's are expected to fail because of it? I'm using a bunch of ANE's and not quite sure which one is dependant on firebase.

[Ender22]

Have tested it on XCode 13.4.1 and it seems to package fine, yay. Thanks guys

[Ender22]

Wait crap no. It doesn't compile on XCode 13.4.1, I tested the wrong ane version. So I'll need to buy a new Mac for this. Can I go back to the question of what other ANE's are expected to fail if I use the older com.google.firebase.core? Maybe it affects some functionality I don't actually use?

[marchbold]

@Ender22 The hidden costs of Apple development hey...

I would suggest if you are trying to maintain an older version that you use APM to install versions prior to this latest update. Don't just install a lower version of com.google.firebase.core but pull a version of all the extensions at a specific release. If you were using apm your lock file would have contained the details and you could just revert your version control to that version? Otherwise you can try just downloading the version from the github repositories

[Ender22]

Yes, I'm using APM.

Hmm okay, looking at my lock file has left me a bit confused. I use the following extensions:

• Application
• Application Rater
• Camera Roll Extended
• CameraUI
• Dialog
• Flurry
• Media Player
• Native WebView
• Network Info
• Notifications
• PDF Reader
• Push Notifications
• Scanner
• Share

From the lock file, it looks like com.google.firebase.core is used in: com.distriqt.playservices.CloudMessaging com.google.android.datatransport and those are part of google play services right?... and I don't really understand from my list of extensions which is using google play services, we don't try to do anything directly with that.

Additionally, since google play services aren't used on iOS, I guess nothing will stop working? I've done some tests today and all ANE's seem functional with the older firebase core.

Sorry, I'm a bit lost. Do you know offhand which one of my extensions is causing the firebase.core requirement, so I could roll back just that specific extension?

[marchbold]

Okay, so looks as though you could probably remove this extension for the ios build. It is required for Firebase services which is likely getting included as you are using Push Notifications which uses FCM on Android. We are working on getting platform dependant builds working with apm but it's only partially implemented so far.

Currently you could try either manually removing it, or setting up an alternative apm project config for ios and installing the APNS variant of the push notifications extension.

[marcanw]

@marchbold Due to this issue, I'm stuck with older ANEs.

I have two questions:

1. Are the latest versions of the ANEs required for Android 33?
2. As I understand it, the problem arises when building iOS on Windows, but this concerns an ANE that is only required for Android (referring to your last post). Perhaps I'm overlooking something. Could you clarify?

Thank you for your response.

[marchbold]

@marcanw

1. I believe the previous version of the majority of our extensions supported API 33. This latest update is to support the latest Google services (Firebase/Analytics/FCM etc) which included several bug fixes from Google.
2. com.google.firebase.core is required by iOS apps supporting Firebase services so not an Android only extension.

[idzdigital]

Can someone please post here once the issue is solved and ANEs are ready for development on Windows. Thanks

[Michoko92]

Michael pointed me to this thread, and the discussion about possibly dropping the iOS support on Windows. Honestly, this AIR feature is probably the most precious and unique to me, compared to other SDKs. Every time I check new SDKs or engines, the first thing I look for is how to build for iOS target. Until now, all the alternatives I saw can only build on an Apple machine. As an experienced Windows user, being able to build all platforms on my dev machine is a comfort only AIR offers, and it is invaluable.

I'm sure that, knowing Apple, maintaining iOS support must be a very challenging task. But honestly, this is something that could definitely be one of the strongest selling points for AIR once marketing is done more actively. Please tell me there is still hope.

PS: I suppose that having a remote building service would be OKish, and it would be better than nothing. But I think that if AIR drops Windows iOS building in a future version, I'll stop updating as long as I can.

[ajwfrost]

Hi

Thanks @Michoko92 for the input. The support for iOS on Windows is a tricky one, but we think we may have a route forwards for it. To link in another thread: the below is our tracking one for the 'undefined symbols' problem when building on Windows. https://github.com/airsdk/Adobe-Runtime-Support/issues/2299

We're investigating still - particularly the updates that may be coming along with Xcode 15 - but I would say that there is now some hope! We do now have some updated ld64 code from Apple which we hope supports the msgsend selector stubs, so will be looking into this now.

thanks

[MatseFR]

Hi, Michael pointed me to this thread as well. I do have an old mac mini, I updated it and it's now running Monterey and XCode 14.2

I'm not a mac user at all but after hours of hairpulling I finally managed to run ADT with the latest AIR SDK... only to get the same "Undefined symbols for architecture arm64" error, which is quite disappointing to be honest.

Do I need a mac that can run XCode 15 ?

Here is the command I used, do I miss something in there ?

adt -package -target ipa-app-store -provisioning-profile appstore.mobileprovision -storetype pkcs12 -keystore ios_dist.p12 -storepass xxxxx app.ipa application.xml -C icons/ios/ . -C bin . -extdir ane -platformsdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS16.2.sdk/

[ajwfrost]

Hi

Definitely don't update to Xcode 15.. the fact you're getting this on a mac is odd though .. possibly you could remove the "platformsdk" argument in case that's confusing things?

Is your mac mini an Intel one? And are the missing symbols all ones that have "objc_msgsend" in the name?

thanks

[Michoko92]

Thank you @ajwfrost , this is excellent news! Keep up the amazing work, you and your team are really appreciated. 🙏

[MatseFR]

@ajwfrost Thanks for replying, I get the same error when removing the "platformsdk" argument

My mac is an intel one yes, however there is no occurence of "objc_msgsend" in the error log (attached to this post), a lot of FirebaseXXX occurences though (I do use Firebase for push notifications using distriqt's ANE) error_log.txt

edit : forgot to mention I rebuilt the whole project using APM (it's an old one, this was just supposed to be a quick maintenance update 🥲 )

off topic but by the way, can I safely put my AIR licence file on my Mac if it's already on my PC ?

[marchbold]

@MatseFR This looks like a separate issue, open a new issue in the Firebase repository and we'll help you through it. Definitely remove the platform sdk option, and make sure you have v14 of Xcode installed (do not install 15 yet!)

[MatseFR]

@marchbold I couldn't install Xcode 15 even if I wanted to : my Mac is "too old" (thanks Apple for programmed obsolescence !)

I don't use the Firebase ANE (at least not directly) : I use FCM for push notifications, shouldn't I open an issue in the Push Notifications repo instead ?

[marchbold]

Yeah PushNotifications extension would be appropriate then.

[idanasher]

I want to buy a new mac in order to be able to compile... I'm debating between two mac(s) and I would love to get a recommendation\suggestion if it matters to the development process and also would like to know which operating system, and XCode version I should have on this new mac I want to buy.

These are the option:

(1) Mac mini M2 Pro Chip (2) Mac Studio M2 Max

[MatseFR]

@idanasher Right now you need XCode 14.3, which requires at least macOS 13

You can install previous versions of XCode from this link (requires an apple dev account) https://developer.apple.com/download/all/

If you end up with several versions of XCode installed you can choose which one should be used by command line tools such as ADT by launching XCode and going to Settings > Locations > Command line tools

Also if you are a windows user like me and want to buy a mac just to package IPAs you might want to consider other possibilities first : if you have a friend/colleague/whatever with a mac that is recent enough and that person is ok to let you use it you can just use remote desktop software such as https://rustdesk.com/ (which is extremely easy to use) to package your IPA. That's how I did it a few days ago using my brother's mac

[marchbold]

@idanasher Unless you need the extra power of the studio a mini is perfectly fine for AIR development. We actually use a mac mini as a build server for a range of projects, including AIR and Unity.

Currently use Xcode 14.3 (the one released last week 15 requires some updates from AIR before it will be compatible, Harman are aware and working on it). Similarly would suggest using macOS Ventura (13.5)

[marcanw]

Is there any hope that Harman will finally find a solution for Windows, or is it hopeless?

[ajwfrost]

Well we got the "latest" code for the linker from Apple .. but that's from Xcode 13 it seems, and doesn't handle these objc_msgSend stubs. So we're looking to see whether we can generate an object file that would contain the definitions... which is an interesting challenge! And once we've done that, we'd need to then get this all building on Windows.

I wouldn't say hopeless, but it's technically quite challenging.. I'll try to provide an update at the end of next week to let you know whether we've managed to get it working on the mac platform, and if so then it's "just" a case of getting the Apple linker to build on Windows. It would really help though if Apple released the Xcode 14 linker source code :-(

[marcanw]

Thx @ajwfrost for your update. I hope you guys will find a solution.

[ajwfrost]

@marcanw @Michoko92 can you please try downloading the folder from the below link, this should replace the lib\aot\bin\ld64 folder in your AIR SDK. This contains a new build of the linker, using LLVM's rather than Apple's source - it's worked in our internal testing but it would be good to know if this also runs and builds/links for your apps..

https://transfer.harman.com/link/BxsZukLF5pKkU6XKAzcVO6

thanks

[Michoko92]

Hi @ajwfrost , so I first downloaded the latest version of the AIR SDK (50.2.3.6), without the new linker, and when I tried an iOS build, I got this error message:

ld: unknown option: -platform_version

Then I downloaded the files above, and replaced the linker, and now everything seems to work fine. Good job!

Just wanted to tell you that some people may encounter the same -platform_version error with the vanilla 50.2.3.6 version, though?

Also I want to precise I was not encountering initially the same issues as @marcanw , as I am not using the ANEs that may trigger this error. But at least regular iOS building works fine for me . Cheers!

[ajwfrost]

Thanks - yes it's a bit in flux at the moment, we may need to do a quick update to 50.2.3.6 to update the linker command for Windows prior to pushing out a version that actually uses the new linker.. sounds like there are still some issues to sort out with that :-(

[marcanw]

I started to test a build that was compiling flawlessly with 50.2.3.5 before upgrading to last ANEs that was creating problems.

As Michoko92, I had the same issue with the vanilla 50.2.3.6:

After replacing ld64, I get the following error:

I don't know if I migrate to the last ANEs it would solve the problem. Maybe @marchbold knows more about it.

[marchbold]

@marcanw That is a separate issue, I've got a fix for it I'm rolling out shortly.

[marcanw]

@marchbold Ok, so if I update the Firebase ANE, it will solve the issue, right?

[mrfrasier]

@marcanw @Michoko92 can you please try downloading the folder from the below link, this should replace the lib\aot\bin\ld64 folder in your AIR SDK. This contains a new build of the linker, using LLVM's rather than Apple's source - it's worked in our internal testing but it would be good to know if this also runs and builds/links for your apps..

https://transfer.harman.com/link/BxsZukLF5pKkU6XKAzcVO6

thanks

@ajwfrost Any chance for an updated link? I'm also facing the same issue and popped in to see if there was an update, but seems the file transfer has expired

[ajwfrost]

@mrfrasier there's an updated version - this link will work hopefully for the next month... https://transfer.harman.com/link/Brh2YO2NAELPL99TZbgimo We need to push out a couple of releases to get this properly out into the SDK, had hoped to get that done before month-end but it will be a little delayed..

[mrfrasier]

Thanks @ajwfrost, that resolved the platform issue, but I'm still unable to build. Looks like there's a bunch of issues with duplicate symbols and Bolt?

I've got the Firebase and PushNotifications-FCM anes going. Removing those allowed me to submit last time, but obviously I then lose the ability to send push notifications haha

[ajwfrost]

The "updated" one here was the LLVM linker with updates to switch errors (caused by duplicate symbols) into warnings, the Apple ld64 linker seems to ignore these.

But actually, those all should just be outputs that warn about duplicates, but the final linkage/output should still work? Are there any lines that start with 'error'?