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