Bug / Crash iOS Xcode build stuck

[Bayasgalanl]

Haven't had the time to test it yet, my apologies. Will do today, tomorrow morning in the worst case, and get back to you once done.

Same here

Obi Fluid 5.0 and Xcode 11.4 (11E146)

[Gleb Palchin]

Just for your info, old version of Obi (4.3) also doesn't build in the new xcode, even if earlier it was working, like a few months ago.

[josemendez]

Just for your info, old version of Obi (4.3) also doesn't build in the new xcode, even if earlier it was working, like a few months ago.

Both versions of Obi run fine using xcode 11.3, so it is definitely a xcode issue. Will test and get back to you asap.

[Gleb Palchin]

Both versions of Obi run fine using xcode 11.3, so it is definitely a xcode issue. Will test and get back to you asap.

Hey, any results before apple makes the 11.4 update mandatory?

[josemendez]

Hey, any results before apple makes the 11.4 update mandatory?

Depends entirely on how/when Apple responds to my bug report (posted a screenshot of it in this thread: http://obi.virtualmethodstudio.com/forum...p?tid=2124). No response yet, but it's been weekend so let's give them a few days.
This is a serious bug btw, as most static libraries I've tried to link against cause 11.4's linker to hang.

I can't do anything from my end. Unity forces native plugins to be statically linked in iOS, so though luck. Unfortunately we're in their hands .

[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.

[sdpgames]

To recreate the problem do this steps:
1. Create an empty Unity project in Unity 2019.2.20f1
...

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.

---

Depends entirely on how/when Apple responds to my bug report (posted a screenshot of it in this thread: http://obi.virtualmethodstudio.com/forum...p?tid=2124). No response yet, but it's been weekend so let's give them a few days.
This is a serious bug btw, as most static libraries I've tried to link against cause 11.4's linker to hang.

I can't do anything from my end. Unity forces native plugins to be statically linked in iOS, so though luck. Unfortunately we're in their hands .

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

---

I'm pretty sure it has something to do with xcode.

As said, Obi's physics engine comes precompiled (the libOni.a file) and the C# wrapper is compiled by Unity when generating the xcode project. So all Obi related code arrives at xcode compiled and ready to be run. For some reason, xcode is choking when linking the project, but really sounds like a xcode issue. It should either link successfully, or return a linker error, not get stuck forever.

What Xcode version are you using, btw?

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

[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)

[davidsedrakyan]

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:

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.
-------------

See the above link.


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)



Any news on this ?