Bug / Crash iOS Xcode build stuck

[josemendez]

Exact same bug, Catalina 10.15.2, Xcode 11.5, Unity 2019.3.12f1

It's an Obi thing, we have done 10 projects and released 3 with these configuration, without any problem.

Apple engineers themselves have confirmed it is a bug in Xcode, first introduced in 11.4, and that they're working on fixing it. They proposed a temporary workaround that sadly, does not work. Obi compiles and runs fine using all previous XCode versions, and all other toolchain/compiler combinations (we have a different IDE/compiler/linker for each platform, which are quite a few. The only one failing is XCode).

See the main thread about this issue: http://obi.virtualmethodstudio.com/forum...p?tid=2124, copy pasting the relevant post here:

-------------
Good news everyone: Apple has confirmed this is a bug in XCode, and suggested a potential workaround:

Their response:

Engineering has provided the following information regarding this issue:

The libOni.a library contains bitcode files, therefore we must do LTO in order to build this project.

Breaking into the process as it’s hung, it seems to be stuck on this function:
_ZN3Oni25CookedSkinConstraintBatch18EvaluateConstraintEPNS_22BatchedConstraintGroupINS_18SkinConstraintDataEEEiif

You may be able to work around this issue if you can add the following attribute to the function:
__attribute__((optnone))
void examplefunction() { return; }

This will prevent the link-time optimizer from trying to process the function and hopefully avoid the hang.

We are working to resolve this in a future release.

In other words, the culprit is indeed link-time optimization (LTO), which I tried to disable before without success. Since the library contains bitcode files (to be able to deploy to the store), LTO is mandatory. However the linker gets stuck trying to optimize a specific function. The workaround they propose is flagging that function with (optnone), to prevent the linker from attempting to optimize it and getting stuck.

They also mention they're working to fix the linker in an upcoming update. In the meantime, I will try their workaround and see if it actually works.
-------------

An update would be appreciated, it's been two month. Thanks

See the above link.

I don't think this is how it works anymore. Your code is compiled to an intermediate language using bitcode, the actual machine language is generated later (probably at link time). So there is definitely some sort of compilation going on at link time. It can also happen on the App Store servers if you choose so

https://medium.com/codebbkaf/what-is-bit...dd8a434af8

When you compile a static library (like Obi), you're generating binaries with a bitcode section at the end (if you enable it), which is then used when compiling and linking another program against the library. According to what Apple explained to me in the original bug report, when linking against bitcode language Clang always uses LTO (link time optimization: http://johanengelen.github.io/ldc/2016/1...n-LDC.html) regardless of whether or not you actually enabled it for the current build target. This is probably what you referred to as "compilation at link time", which is close. However, LTO is hanging in an infinite loop when optimizing one specific function in Obi.

Needless to say, this should never happen: a well behaving linker should either fail to link with an error message, or link successfully. Hanging when linking is always a bug in the linker, regardless of what the library contains. Same for a compiler, or any other part of the toolchain. Their proposed workaround was to temporarily disable optimization for that specific function, marking it with clang's optnone attribute. Turns out, the linker just hangs in the next function . Disabling optimization for all functions is out of the question, as performance would plummet.

Obi uses C++11 features quite extensively (smart pointers, threads, condition variables, lambdas, atomics, etc), so my guess is that LTO is choking on a particular combination of these. Still there's nothing we can do to fix this ourselves, short of rewriting our entire physics lib (which we are actually doing, see: http://obi.virtualmethodstudio.com/forum...p?tid=1619)