XCode can not build UnityWebRequest.o

Hi

ld: b(l) ARM64 branch out of range (136049796 max is +/-128MB): from +[UnityURLRequest storeRequest:taskID:] (0x00006F60) to __Unwind_Resume@0x00000000 (0x081C64D0) in ‘+[UnityURLRequest storeRequest:taskID:]’ from /Users/xxx/Library/Developer/Xcode/DerivedData/Unity-iPhone-axjxbqexywgtvtcndrhyokjjgstl/Build/Intermediates.noindex/Unity-iPhone.build/Debug-iphoneos/UnityFramework.build/Objects-normal/arm64/UnityWebRequest.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Unity 2020.2.4f1

How can we workaround this?
I even dont know where to start

Do you end up have a VERY LOT of generated C++ code in your project?
The error indicates that the resulting machine code is so huge that you hit the limitations. To solve this you need to either reduce the code (are you using engine code stripping?) or have a look at clang linker options, maybe there is an option for generating different machine code for branching.

Android easily builded and sizes are:

  • libil2cpp.so 311 MB
  • managed dlls 24 MB
  • il2cppOutput 1228 MB

I dont know exactly is it too much or not. il2cpp always been x50 to managed Code
If this is too much, how can we understand why il2cpp create so much code from such small codebase?

Yes we are

Actually nothing changed in xcode project just build.
Will try to find some useful settings.

Does it compress well enough for you? Because you risk exceeding the store limitations:
https://developer.android.com/google/play/expansion-files

It mostly comes does to how compiler lays things in the executable. iOS and Android use different linkers, so there can be difference, but what concerning is that you seem to be pushing stuff to the limit.

Thanks. We already on google play store, use android app bundles and play asset delivery

Now trying to build for iOS.
Builds stop building few days ago.

Can you please clarify what average ilbil2cpp.so and il2cppOutput size considered normal?

There are no “normal” here. Just having apk size limited to 100MB the 300+MB library even when zipped should put you not that far from the limit.
The things to watch for are C# generics, which can easily explode in size, and any libraries (including .NET standard one) that you use, maybe some can be avoided.

@JesOb I think that 1GB of generated code is really a lot for most projects, certainly it is too much if you consider this to be a small project.

Can you try this project with the latest 2021.2 beta? If so, please try the “IL2CPP Code Generation” option “smaller (faster) builds” in the Build Settings window. That should minimize the cost of generics in code size by doing much more generic sharing. I’m curious about how that impacts the build size.

Also, is this a project you can share via a bug report? We may be able to have a look and better understand where the large code size is coming from.

@JoshPeterson
Hi, I am having the same problem right now.
And it is not caused by a change in the code, but by a Unity version upgrade. (2020.3.18 → 2020.3.42)
My project is already released, so it is difficult to raise it to 2021. And I want to use the bug fixes that came in 2020.3.26.
Do you know up to which version I can raise it?
Also, like myself, there are people who say that it occurred when they raised it to 2020.3.33.
This comment section.
https://issuetracker.unity3d.com/issues/ios-arm64-branch-out-of-range-747396072-max-is-plus-slash-128mb-xcode-error-when-building-development-build-with-script-debugging

Same here after updating 2021.3.12f1 to 2021.3.15f1

“Strip engine code” is disabled on both versions of Unity, 2021.3.12f1 builds fine, 2021.3.15f1 crashes with the same error above. Enabling “strip engine code” on Unity 2021.3.15f1 fixes the issue.

Additional information.
In my environment, “Strip engine code” is enabled and “strippingLevel” is set to Medium, but with 2020.3.42, I get an error.
If I set “strippingLevel” to High, the build passes, but looking at the size of the C++ code, I think this too will soon reach its limit.

Do you have the “Script Debugging” option enabled in the Build Settings? That is the trigger for the problem in https://issuetracker.unity3d.com/issues/ios-arm64-branch-out-of-range-747396072-max-is-plus-slash-128mb-xcode-error-when-building-development-build-with-script-debugging.

Oops, my bad.
I always turn off ScriptDebugging.
But doesn’t this mean that the C++ code on the Engine side has increased significantly recently?

Yes, if you are seeing an error with script debugging disabled (and it sounds like that is the case), then something else is happening which is unexpected.

Can you post the specific error message here?

Do you need a full log?
It looks like the same log as when it goes through normally until just before this.

❌ ld: b(l) ARM64 branch out of range (134537264 max is +/-128MB): from +[UnityURLRequest storeRequest:taskID:] (0x00006DA0) to __Unwind_Resume@0x00000000 (0x08054E8C) in '+[UnityURLRequest storeRequest:taskID:]' from /Users/oinkun/Library/Developer/Xcode/DerivedData/Unity-iPhone-ajjzuruupamzzwghesapudcjmrac/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/Unity-iPhone.build/Debug-iphoneos/UnityFramework.build/Objects-normal/arm64/UnityWebRequest.o

❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)

** ARCHIVE FAILED **

The following build commands failed:
Ld /Users/oinkun/Library/Developer/Xcode/DerivedData/Unity-iPhone-ajjzuruupamzzwghesapudcjmrac/Build/Intermediates.noindex/ArchiveIntermediates/Unity-iPhone/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/UnityFramework.framework/UnityFramework normal (in target 'UnityFramework' from project 'Unity-iPhone')
(1 failure)
[08:38:02]: Exit status: 65

Thanks for the details. To be clear, does this happen when script debugging is not enabled?

Yes.
Script Debugging is off.

I don’t know of any specific changes in Unity during that timeframe which would have significantly increased the code size. I suspect that this project was always right on the edge, and some small-ish change pushed it over the line into this problem.

You can try a work around - set the IL2CPP_LARGE_EXECUTABLE_ARM_WORKAROUND define in Xcode when you compile. See the code in the il2cpp-config-platforms.h header file for some details in a comment. This will avoid this linker problem, but it will make managed stack traces less reliable. It is not a great solution, but might work for the time being.

3 Likes

That is an excellent suggestion.
I’ll try it tomorrow!
Thanks!

This worked perfectly on my project!
Thank you so much!


To others who have seen this thread.
IL2CPP_LARGE_EXECUTABLE_ARM_WORKAROUND is not added to the Unity defines, but to the Xcode defines.
I was using fastlane to build, so I added the following option to xcargs.

xcargs += " GCC_PREPROCESSOR_DEFINITIONS=\"$(inherited) IL2CPP_LARGE_EXECUTABLE_ARM_WORKAROUND=1\""
1 Like