Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 1102 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
FATAL:Section too large, can't encode r_address (0x1210368) into 24-bits of scattered relocation entry
It probably means the application is huge.
Zoltan: "When compiling it in Windows it gets about 7 Mb large" (from assistly)
We are seeing this as well.
FATAL:Section too large, can't encode r_address (0x1026238) into 24-bits of scattered relocation entry
We are still seeing this issue. The only way we can get around it is to compile with the llvm option on. This prevents us from being able to debug on the device, which can be extremely frustrating. Any progress being made with this? I'm happy to provide any information needed about our setup.
This is an excerpt from the build log showing the error message:
Process exited with code 1, command:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -gdwarf-2 -miphoneos-version-min=4.0 -arch armv6 -std=c99 -I/Developer/MonoTouch/SDKs/MonoTouch.iphoneos.sdk/usr/include -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -c /var/folders/G4/G4sImOoZGJCQlBGMhWeMJU+++TY/-Tmp-/tmp213a7d85.tmp/Sketch.Busi.dll.6.s -o /var/folders/G4/G4sImOoZGJCQlBGMhWeMJU+++TY/-Tmp-/tmp213a7d85.tmp/Sketch.Busi.dll.6.o -DDEBUG
/var/folders/G4/G4sImOoZGJCQlBGMhWeMJU+++TY/-Tmp-/tmp213a7d85.tmp/Sketch.Busi.dll.6.s:unknown:FATAL:Section too large, can't encode r_address (0x113ab88) into 24-bits of scattered relocation entry
Sorry about this, but if you could upload all the assemblies you have, it would make it a lot easier to try this (I can likely figure it out anyway, but it would definitively help having all the assemblies since otherwise I'd have to write mocked versions for those I don't have).
Thanks for the test case, we were able to reproduce it now.
Unfortunately the initial guess is correct, it is a matter of size. The assembly in question is not that big, 2.1 mb, but the AOT compiler generates a 100mb file with arm assembly and when using GCC to compile that assembly file to an object file we hit a 16mb size limit on the generated code (this is a limitation in the arm object file format we can't do anything about).
The first thing you should ensure is that you're linking all assemblies, if you're not doing that it might very well fix the problem. If that's not enough or you're already doing it the second thing you can do is to split the assemblies where this happens into smaller assemblies (which is not a good nor easy workaround of course). We're discussing ways to fix this in better ways, but it's not easy/small fixes so it will take some time until we get it done.
What I sent you was not linked. I tried setting it to link all and it builds without any errors but that build fails to run with the previously mentioned "segmentation fault 11" on launch. Which was determined to be caused by thumb instructions sneaking there way into our static lib. I'm going to take closer look at how we are building the static lib for our project. I know for a fact that compile for thumb is set to off.
Right, that thumb issue has (hopefully) been resolved, the fixes are being tested now and should get into the next MT release.
I've found the source of the thumb instructions in our static lib and have made sure they are no longer being included (otool). It builds fine but when I go to run it on a device I get the following error:
Job appears to have crashed: Illegal instruction: 4
Brian, my guess would be that the additional mtouch arguments aren't correct. Even if that's not the case it's not this bug, so please open a new bug report for it with a test case.
From the comments it looks like this bug was fixed, but a separate issue "Illegal Insturction 4" needs to be filed.
Closing for now.
The comments are confusing, this bug hasn't been fixed (comment #11 is about this bug, the ones after that one are not).
Is there any update or ETA on this bug? Last night, I had to implement this fix, but my project relies pretty heavily on reflection, and a bunch of necessary symbols got stripped out because they are never referenced directly.
Fortunately, there is a step I can take now that isn't all that painful to break up my assemblies, but I'm worried that will only work as a stopgap (I'm porting a rather large project to the iPad), and that one of my assemblies will end up growing too large for this boundary again, at which point I'll be quite stuck indeed.
*** Bug 7499 has been marked as a duplicate of this bug. ***
We are seeing this same problem when trying to build a debug build for the device. Not being able to debug on the device is a nuisance now, but we are only in the investigation phase of a new app. It will be a huge problem once we start porting the majority of our code to MonoTouch.
FATAL:Section too large, can't encode r_address (0x10eaee8) into 24-bits of scattered relocation entry
Grant, try enabling the managed linker (in the project's options, iPhone Build page, select "Link SDK assemblies" or "Link all assemblies" for "Linker behavior"), it will usually work around this problem quite well.
We currently have our iPhone Build settings as "Link SDK assemblies only." Changing it to "Link all assemblies" builds correctly. Evidently we tried this before, but it causes our app to crash on launch due to our extensive use of MEF and composition. Would it be possible for the linker to look at other attributes than the [Preserve] attribute to keep these pieces around? Maybe the Export attribute could imply Preserve? Others on the team have made a few attempts to mark all our needed pieces as [Preserve], but none has been successful thus far.
I do not recall if MEF uses another [Export] attribtue - but the one from MonoTouch cannot be changed to [Preserve].
OTOH there's several ways to customize the linker, [Preserve] is only one of them.
You can also use "Link All" and then turn off linking for one (or more) specific assemblies using --linkskip=ASSEMBLY (without .dll or .exe).
You can also use an XML file instead of [Preserve]. That's useful when you do not have the source code (to modify) for the code you want to preserve (e.g. MonoTouch provided assemblies or 3rd party code).
In your case you could write a simple tool that create entries for all your [Export] code (and re-run it when your assembly change and before using mtouch).
The latest ServiceStack.Text will not work on monotouch because of this issue. Splitting it into multiple assemblies is not trivial because there is no clear file dependency structure within the project. Any other workarounds suggested?
Felix, the current workarounds are to enable the managed linker (comment #21), enable LLVM (comment #5), split the assembly into multiple smaller assemblies, or remove/comment out/ifdef out pieces of code from the offending assembly you know you're not going to use.
What is the timeline for getting this fixed? We are having to drop using ServiceStack in our project because the latest touch release 3.85 is way behind the head and has bugs, we can't use the latest head because it will not compile due to this bug. I see this has been open for over a year which is quite a long time for a bug marked High critical.
Actually, I'm not sure if this is the same issue now. I get... "Error MT3001: Could not AOT the assembly...." I've opened another ticket
Fixing this problem requires a fairly large rewrite of our code generator, which is why the workaround is to link your assemblies.
Without linking, you are including very large swats of code that are never used. So you should always use linking. If you have specific problems with linking, you could look into providing a link descriptor to instruct the linker to not remove specifics bits of code, see:
For more details.
*** Bug 11274 has been marked as a duplicate of this bug. ***
This bug was targeted for a past milestone, moving to the next non-hotfix active milestone.
*** Bug 9002 has been marked as a duplicate of this bug. ***
*** Bug 18860 has been marked as a duplicate of this bug. ***
*** Bug 19605 has been marked as a duplicate of this bug. ***
*** Bug 20879 has been marked as a duplicate of this bug. ***
*** Bug 15904 has been marked as a duplicate of this bug. ***
*** Bug 28700 has been marked as a duplicate of this bug. ***
Workarounds are provided for this issue and based on comment #28, I am moving the target milestone.
I'm closing this bug, because there is no general solution here.
We can always make improvements to our AOT compiler that will decrease the executable size (which we do), but that only means we'll hit the limit with more managed code, not that we've removed the limit.
For projects that run into this problem, please file separate bug reports for each of them (since each project is different and will exercise the codegen in different ways), and we'll have a look and see if our codegen can be improved for each particular project.
Re-opening as it has proven useful to track duplicates in a single place.
Note that a lot of data is historical (e.g. gcc->clang, it's a 32bits-only issue) and some comments are not related to the bug.
Another potential workaround for apps running into space issues like this showed up in bug #51226: add "--mono:framework" to the additional mtouch arguments, and the mono runtime will be included as a framework in the app, instead of linked statically into the main executable.
*** Bug 51226 has been marked as a duplicate of this bug. ***
*** Bug 23191 has been marked as a duplicate of this bug. ***
*** Bug 52983 has been marked as a duplicate of this bug. ***