Replies

append delete 21 Nov ’22 · 18:55 #1. Kris Rok

Hi Michele,

funny we both stumble upon the same problem the same day, see my post from a few hours ago.

Did you manage to successfully compile any ARKit/AR Foundation project prior? Maybe with lower package versions?

append delete 22 Nov ’22 · 09:09 #2. Kris Rok

Ok, with the same setup as you (except Win10) I had no success with AR Foundation versions 4.2.7 as well as 5.1.0-pre2 using the samples projects provided by Unity:

https://github.com/Unity-Technologies/arfoundation-samples/tree/4.2
https://github.com/Unity-Technologies/arfoundation-samples/tree/main

:: @Kris Rok added on 22 Nov ’22 · 09:10

Both fail with the missing symbols.

I wonder if this ever worked? E.g. with an older version of iOS SDK?

:: @Kris Rok added on 22 Nov ’22 · 11:26

Now I tried to manually (!) downgrade from iOS SDK 16.1 to 15.5 using this repo:
https://github.com/xybp888/iOS-SDKs/releases

With this "15.5" and 3.53 it still fails with the same errors.

If I knew how to properly downgrade the iOS SDK or the Build Environment I'd go deeper down this rabbit hole ;)

With Xcode the projects build just fine (while still exported in Unity-Windows).

append delete 22 Nov ’22 · 11:06 #3. Michele

Hi Kris,

I have no error compiling ARKit Unity projects until about two months ago. Unity, ARKit, Ar Foundation, iOS Project Builder and the iOS SDK were older.
In particular, I remember that it worked for me with SDK 15.2, but yesterday I tried to use it (but without going back with Unity, ArKit, AR Foundation and with iOS Project Builder) and it doesn't work.

Let's hope that Pierre-Marie will answer us...

append delete 22 Nov ’22 · 12:05 #4. Pierre-Marie Baty

Hello

@Kris Rok: if you "manually" downgraded your iOS SDK it won't be properly deployed and most likely unusable. You *MUST* take it from macOS and run the "Migration Assistant (step 1).command" script on it so as to lay out the files properly in the zip archive. The directory layout of the SDK on Windows is not the same as the directory layout of the SDK in Xcode !

@Michele: you haven't provided a link to the build log, that's unfortunate. But since several people seem to have the same issue there might be something to fix so I'll have a look at it. Can you please send to my email address pm at this domain dot com the very Xcode project that you're trying to build ? Delete the "build" directory to save space in the archive. Thank you in advance.

append delete 22 Nov ’22 · 12:13 #5. Kris Rok

"Manually downgrading" the SDK was mereley a failed attempt showing how desperate I am :)

As I just freshly builded the 4.2 samples (see above) I'm already busy uploading an archive for you. It's likely not the exact same version Michele mentions but it has the exact same errors.

append delete 22 Nov ’22 · 14:20 #6. Michele

@Pierre-Marie: email sent.

Thank you.

append delete 22 Nov ’22 · 16:12 #7. Pierre-Marie Baty

Your emails were received, I'll be looking at it and post back.

append delete 22 Nov ’22 · 16:16 #8. Kris Rok

Great, thanks! Looking forward to it.

append delete 23 Nov ’22 · 14:14 #9. Kris Rok

Quick update: Using Unity 2020.1.17f I managed to successfully build the 3.1 samples from here:
https://github.com/Unity-Technologies/arfoundation-samples/tree/3.1

This is 2 years old though, mabye newer versions work too. I've already wasted too much time on this to dig even deeper.

But maybe it could still be interesting to compare the architecture of the iOS library versions:

Here's the _working 3.1.8_ one:
https://github.com/needle-mirror/com.unity.xr.arkit/tree/3.1.8/Runtime/iOS

and here's the _non-working 4.2.7_:
https://github.com/needle-mirror/com.unity.xr.arkit/tree/4.2.7/Runtime/iOS

Maybe it helps.

append delete 23 Nov ’22 · 15:13 #10. Pierre-Marie Baty

All I can say right now is that the bug is confirmed and I'm working on it. I have no clear idea yet why it doesn't link, but I'm investigating.

:: @Pierre-Marie Baty added on 23 Nov ’22 · 15:29

Alright, the cause is found : Xcode 14's Objective-C msgSend selector stubs.

https://stackoverflow.com/questions/73992337/flutter-build-is-ios-error-xcode-undefined-symbol-objc-msgsend
answer #1 by Jackson

https://stackoverflow.com/questions/8349439/linker-cant-find-objc-msgsend-and-many-other-symbols
answer #2 by bleater

Now on trying to find a fix or workaround.

:: @Pierre-Marie Baty added on 23 Nov ’22 · 15:39

Ah, fantastic Apple : https://github.com/llvm/llvm-project/issues/56034

“This new feature is enabled by default in Apple clang 14, *and doesn't seem to be in Apple's public fork*. It can be disabled in the meantime by passing -fno-objc-msgsend-selector-stubs to all clang compiles.”

Looks like a compiler and linker upgrade will be necessary to build this project correctly.

The reason is that Unity built their libUnityARKit.a library using an unpublished optimization present in Xcode 14 and currently only the Apple linker is able to digest it.

Perhaps you can ask the Unity guys to publish an update of this ARKit sample with the Objective-C msgSend selector stubs optimization disabled ? That would enable the builder's toolchain (which is based on Apple's LLVM public branch) to build it.

:: @Pierre-Marie Baty added on 23 Nov ’22 · 15:41

In the meantime I'll try to rebuild a toolchain based on LLVM 16. That optimization should be featured in it.

append delete 23 Nov ’22 · 16:46 #11. Kris Rok

Good work! I'm a bit sceptical Unity's behemoth of a dev team will provide us a version compiled without the feature in time -- but who knows.

Hmm, just to get the gist of this right: You'll try to replace apple's custom (and at least in this regard, proprietary) fork of clang (and surrounding tooling) with the mainline one and hope for feature parity with what Xcode uses? Uh-oh... hope that'll work, good luck! :) You gotta love apple for bitch moves like this.

append delete 23 Nov ’22 · 20:20 #12. Pierre-Marie Baty

Apple maintains their own open source branch of LLVM. That's the one I use. The problem is that they publish their changes to GitHub way after they've been introduced in Xcode updates. Very often we have to reinvent the wheel because there's a need for it today, knowing that a future patch from Apple will provide the right implementation anyway, but God knows when.

append delete 02 Dec ’22 · 16:21 #13. Pierre-Marie Baty

An update on this topic :

The missing features are supposed to be implemented in LLVM 15. I tried to cross-build LLVM/clang 15 from Apple's branch for Windows from one of their development snapshots. It can't be built because some source files are missing from the snapshot.

It's not really surprising, as it's not a tagged release. But I'd have preferred if their snapshots were buildable.

We'll have to wait til they push a tagged release (these ones are better tested and buildable). Their latest tagged release is swift-5.7.1-RELEASE, which is still based on Clang/LLVM 14.

append delete 02 Dec ’22 · 16:24 #14. Kris Rok

Thanks for the update. Could you provide some rough estimate how long it usually takes for apple to publish new features?

append delete 02 Dec ’22 · 18:18 #15. Pierre-Marie Baty

That's extremely variable !

swift-5.7.1-RELEASE was published on 25th of October
swift-5.7-RELEASE was published on 23th of August
swift-5.6.3-RELEASE was published on 18th of August

As you can see it can happen tomorrow... or in months.

append delete 02 Dec ’22 · 18:29 #16. Pierre-Marie Baty

I'll try to build several others of their development snapshots until I find one that builds. If I can't, I'll try to do my own implementation.

append delete 09 Dec ’22 · 17:20 #17. Pierre-Marie Baty

Good news! I could build a toolchain based on llvm-16-HEAD (the one from the LLVM project, not from Apple) and after a few fixups I could successfully build your test projects @KrisRok and @Michele (note @Michele: your project lists most of its source files with full paths, e.g. C:\iOS\..., instead of relative paths - that's a bad practice, because such projects are not easily relocatable. I think you must have toggled a setting somewhere for that in the Unity Editor). Anyway, both were built successfully.

The downside of this toolchain is that it uses LLVM's linker and not Apple's, in which (the latter) I had made a few useful additions, such as the ability to support the .xcframeworks directory format transparently and the ability to suggest/autofix any missing frameworks.

Another downside is that this toolchain doesn't have a Swift compiler. But that's not a real problem because its support was never completed in this builder. I'll have to look at how to integrate it properly soon anyway.

So we're not ready yet for a release, I still have to migrate a few things - but the way is now clear.

append delete 11 Dec ’22 · 10:05 #18. Kris Rok

👍🚀

append delete 12 Dec ’22 · 16:43 #19. Michele

Thank you Pierre-Marie.
Congratulations for the care you have for our requests, I appreciate it very much.

append delete 12 Dec ’22 · 17:19 #20. Pierre-Marie Baty

I have an installer of a beta version with LLVM 16-git. Do you want to help me validate it and report your observations ?

I think it should "just work" but better make sure before releasing this one in the wild.

https://www.pmbaty.com/iosbuildenv/iosbuilder.php?beta=1

Let me know, and if all goes well it'll be an official update.

append delete 23 Dec ’22 · 14:36 #21. Michele

Hi Pierre-Marie.

Unfortunately I won't be able to test the beta version until the offices reopen on January 9th as I don't have any personal Apple devices. I'll let you know as soon as the holidays are over. In the meantime, thank you for your care.

append delete 30 Dec ’22 · 22:36 #22. MG

I didn't see anything specific on the missing symbols, but I am receiving something similar.
Using the quick linker results in many symbols being undefined, but then when I use "try to fix unresolved symbols automatically", it eventually (after a long time linking the Unity library) spits out a ton of undefined for: _objc_msgSend

I read that in the latest iOS builder that this problem was fixed, but I am still receiving it.

My setup:
iOS builder 3.54
iOS SDK 16.2

(If you want a new thread for my issue, let me know.)

:: @MG added on 30 Dec ’22 · 23:01

Here is a pastebin link:
https://pastebin.com/S5gwxfFC

:: @MG added on 30 Dec ’22 · 23:24

Note: the previous out put was from "Try to fix unresolved symbols automatically (slower)" option.

Here is the error output when using "Use the LLVM linker (faster)" option:
https://pastebin.com/EAs1av83

append delete 31 Dec ’22 · 11:25 #23. Pierre-Marie Baty

Hello

Indeed you do need to use the LLVM linker to build this project because it uses the new Objective-C msgSend selector stubs. So (until Apple releases their implementation in ld64 to the public domain) you must leave the "Use the LLVM linker" checkbox ticked.

What happens here is that the linker doesn't find one of the Pods that has been built (PromisesObjC). It emits a warning telling that the passed framework directory "build/Release-iphoneos/PromisesObjC" wasn't found, skipping away, and this inevitably leads it to missing symbols (such as FBLPromiseErrorDomain, which is precisely located in that PromisesObjC framework it could not find).

I see anyway that CocoaPods did build that framework successfully (FBLPromises), the problem is that, I guess, it didn't put it in the build/Release-iphoneos/PromisesObjC directory as expected by the linker but most probably in the build/Release-iphoneos/FBLPromises directory. Do you confirm this directory exist ?

If I guess it right, it means something needs to be fixed in the CocoaPods logic.

append delete 31 Dec ’22 · 14:58 #24. MG

Yes, there is a build\Release-iphoneos\FBLPromises directory.

append delete 02 Jan ’23 · 09:52 #25. Pierre-Marie Baty

Interesting. Could you send me your project's Podfile by email at pm at this domain ?

append delete 17 Jan ’23 · 16:11 #26. Michele

Thanks Pierre-Marie, I've tried compiling ARKit projects with iOS Builder version 3.54 and everything works great.

I noticed that this latest release no longer shows the active SDK version in the title bar. It was useful...

I would also like to know if you recommend always using the LLVM Linker from now on, even after Apple updates its implementations.

Thanks again for everything!!!

append delete 17 Jan ’23 · 17:20 #27. Pierre-Marie Baty

@Michele: You're welcome. My recommendation is to use LLVM's linker first, and fallback on Apple's if the first one doesn't work. I'll update both linkers until Apple deprecates their own. LLVM tools (of which Apple is a major open source contributor) are intended to replace Apple's tools in the long run, but it takes a lot of time - it took years for example to move from Apple's binutils to LLVM's binutils, certainly because they wanted to test them in real world conditions thoroughly. Also, my version does print the iOS SDK version on the title bar, maybe you're using a wide font that makes the end of the string cut off ?

iOS Build Environment Help Center

Build error with ARKit and AR FOUNDATION