Getting: "Compiling with code 134" when trying to use the "LLVM Optimizing Compiler" switch

I get a “compilation coming out with code 134” when I try to use the “LLVM Optimizing Compiler” switch to release iPhone using MonoTouch 4.0.1.

I do not get much information from the assembly output window at all: simple:

"Compilation with code 134, command:" MONO_PATH = (snip) /bin/iPhone/Release/LSiOS.app/Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot = mtriple = armv7-darwin , nimt-trampolines = 2048, full, static, asmonly, NODEBUG, LLVM path = / Developer / MonoTouch / LLVM / bin /, output_file = / var / folders / 03 / 033pAAGuHgGkIy4CorbVV ++++ TI / -Tmp- / tmp38107451 .tmp / Newtonsoft.Json.MonoTouch. dll.7.s "(snip) /bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll" Mono Ahead of Time compiler - build assembly (snip) /mscorlib.dll

What is strange is that in earlier command lines there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is compilation, but in this case it says "mscorlib.dll".

Any thoughts?

+4
source share
3 answers

I found several cases (googling and bugzilla.xamarin.com), where the error code 134 is due to the fact that Mono.Linker is too aggressive (removes something you need).

This is easily confirmed by disabling the linker, i.e. Do Not Link in Linker Options. If the assembly works, you can try to isolate the assembly where the linker makes a mistake.

eg. add " - linkskip = mscorlib " to the additional mtouch options and enable the link again. This will link all (Link All) or all SDKs (Link SDK assembly), except for the assembly you have chosen (mscorlib in the example). So that you can fill in only a workaround and an error report, so that the problem can be fixed properly (and get all the benefits of the linker).

However, it should be warned that there are other problems associated with the same error code, for example: http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a

Ymmv

+2
source

mtouch makes its own builds in parallel, so logs can be misleading, for example. you can see a little assembly of X output, and then some assembly of Y output.

Reading the full journal can help you (or us) identify the problem.

+1
source

I had the same Scolestock issue. My application would build a penalty until I turned on llvm, then it was a "Compilation coming out with code 134, command" when trying to create the 7th for the application itself.

I was pleased to say that after two days, carefully distracting my application to the main problem, I was able to isolate the problem from using built-in dictionaries, such as:

Dictionary<enum, Dictionary<enum, value>>

I was able to fix this by defining a class for the inline dictionary and using this instead:

 public class MyDefinition : Dictionary<enum, value> { } ... public Dictionary<enum, MyDefinition> 

Not sure if this will help you, but hopefully this will help some poor soul who decides to use the built-in dictionaries and runs into my problem.

+1
source

All Articles