Bug / Crash Doesn't build for latest XCode (11.4)

[josemendez]

Is there absolutely no solution at all? Can't I send you my project and you compile the library as dynamic and build? Something like that?

As far as I know, Unity does not allow for iOS native plugins to be dynamically linked. Tried in the past, and got a DllNotFoundException. Even the documentation sample code for native plugins has a special case for iOS libs with the comments stating they must be statically linked, unlike plugins for all other platforms:

https://docs.unity3d.com/Manual/NativePlugins.html

Only solutions I see are to use any other Xcode version, or wait for Apple to shed some light on the issue with 11.4.

[numandina]

I can't use older Xcode. Apple updated their back-end too so out of my two games one of them hangs even after uploading to iTunesConnect (stuck at "processing"). This started around the same time Xcode 11.4 was released.

In any case I'll try to write my own implementation that emulates the functionality I had here. For both games (in case the other also stops working).

[josemendez]

Update on this issue.

It's been almost a week since I reported the issue to Apple, haven't heard back from them. I don't know what their average response time is, so let's just wait a bit more.

In the meantime, I've encountered another issues with Xcode 11.4: setting the optimization options to -Os (optimize for speed and size) breaks a lot of floating point math. Weirdly enough, using -O3 works perfectly. Does not happen in previous versions either, so filing a second bug for this.

[JyriKilpelainen]

Hi!
Any update on this Xcode 11.4 issue?

[josemendez]

Hi!
Any update on this Xcode 11.4 issue?

Not yet. Apple haven't responded to the bug report I sent, not even to confirm reproduction or ask for additional info. It's been roughly a week and a half since I sent it, I don't know what their typical response time is. I *really* hope they get back to me soon.

Spent a couple days last week trying to figure out the cause, but had no luck. Tried several libraries and build configurations, some seem to hang the linker, some don't. I could not establish a pattern.

Worst case scenario: we will be able to circumvent this issue entirely once we deploy the Burst based backend for Obi, as it does not require to use native libraries. But that's at least 2 months away, and we don't expect everyone to jump to it immediately as older Unity versions are only compatible with bugged versions of the Jobs package, or outright incompatible. Again, I hope to get some feedback from Apple before this.

[sadiq]

Not yet. Apple haven't responded to the bug report I sent, not even to confirm reproduction or ask for additional info. It's been roughly a week and a half since I sent it, I don't know what their typical response time is. I *really* hope they get back to me soon.

Spent a couple days last week trying to figure out the cause, but had no luck. Tried several libraries and build configurations, some seem to hang the linker, some don't. I could not establish a pattern.

Worst case scenario: we will be able to circumvent this issue entirely once we deploy the Burst based backend for Obi, as it does not require to use native libraries. But that's at least 2 months away, and we don't expect everyone to jump to it immediately as older Unity versions are only compatible with bugged versions of the Jobs package, or outright incompatible. Again, I hope to get some feedback from Apple before this.

Any Update?

[josemendez]

Any Update?

Not yet. Only progress I could make on my own is that the ld process (the linker) hangs while consuming 100% cpu (so probably on a busy loop of some kind, no async wait for anything). Doesn't mean much, actually. Still waiting for Apple.

[josemendez]

Finally some news on this, though not good ones. Apple gave a rather unhelpful response to my initial bug report:



Needless to say, disabling bitcode does not actually solve anything: the linker still hangs. This is easily reproducible using the test project I sent them, so I think they didn't even test their own advice.

Even in the hypothetical case that setting bitcode = NO did allow the build to finish, then it would be impossible to actually publish anything since bitcode is mandatory when submitting to the store. So back to square one.

Just to test Apple's theory ("it didn't hang, its just that bitcode takes a lot of time to link, try disabling it"), I left it running for about 3 hours with bitcode disabled, hoping it would change anything. After that time the ld process (linker) had consumed about 15,4 Gb of ram so I had to kill it.  But while it was running, I sampled the process to obtain stack traces at different times. These are the last lines of the stack 1 minute after starting ld, and also 3 hours later:

Code:

26 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOpt::Level)  (in libLTO.dylib) + 2208  [0x107e82090]
                                           + 20 (anonymous namespace)::DAGCombiner::AddToWorklist(llvm::SDNode*)  (in libLTO.dylib) + 721,1,...  [0x107e811e1,0x107e80f11,...]
                                           + 6 (anonymous namespace)::DAGCombiner::AddToWorklist(llvm::SDNode*)  (in libLTO.dylib) + 221  [0x107e80fed]
                                           +   6 llvm::detail::DenseMapPair<llvm::SDNode*, unsigned int>* llvm::DenseMapBase<llvm::DenseMap<llvm::SDNode*, unsigned int, llvm::DenseMapInfo<llvm::SDNode*>, llvm::detail::DenseMapPair<llvm::SDNode*, unsigned int> >, llvm::SDNode*, unsigned int, llvm::DenseMapInfo<llvm::SDNode*>, llvm::detail::DenseMapPair<llvm::SDNode*, unsigned int> >::InsertIntoBucketImpl<llvm::SDNode*>(llvm::SDNode* const&, llvm::SDNode* const&, llvm::detail::DenseMapPair<llvm::SDNode*, unsigned int>*)  (in libLTO.dylib) + 20,10,...  [0x107e82a44,0x107e82a3a,...]
                                           13 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOpt::Level)  (in libLTO.dylib) + 2236  [0x107e820ac]
                                           + 13 (anonymous namespace)::DAGCombiner::AddToWorklist(llvm::SDNode*)  (in libLTO.dylib) + 360,140,...  [0x107e81078,0x107e80f9c,...]
                                           1 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOpt::Level)  (in libLTO.dylib) + 1122  [0x107e81c52]
                                             1 (anonymous namespace)::DAGCombiner::recursivelyDeleteUnusedNodes(llvm::SDNode*)  (in libLTO.dylib) + 4  [0x107e83284]

So it seems it is forever stuck in a recursive traversal of a dependency DAG (directed acrylic graph) of some sort. 100% sure this is a bug in Xcode now. Exact same lib code compiles and links fine in Eclipse, Visual Studio (MSVCPP), Code::Blocks (MinGW), and all previous Xcode versions.

I've answered to them, with this additional info. Will keep you informed.

[JyriKilpelainen]

Thanks for the update! Let’s hope the next Xcode beta fixes this issue.
This wouldn’t be an issue if Xcode 11.3 uploads would still work but I had the same problem as @numandina: Uploading a game to App Store with Xcode 11.3 makes it stuck in Processing state which fails after 24 hours. Xcode 11.4 upload processing works great and is actually really fast.

These are for games that do not use Obi, that is.

[JyriKilpelainen]

@josemendez @numandina It seems Xcode 11.4.1 is available for download: https://developer.apple.com/documentatio...ease_notes

Maybe it has a bug fix for the issue.