Bug 824 - System.TypeLoadException when using ---gcc_flags
Summary: System.TypeLoadException when using ---gcc_flags
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 4.x
Hardware: Macintosh Mac OS
: --- critical
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
URL:
Depends on:
Blocks:
 
Reported: 2011-09-14 18:08 UTC by Scott Pfister
Modified: 2011-09-15 19:10 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
project that demonstrates the issue -- libLineaSDK.a not included (761.58 KB, application/x-gzip)
2011-09-14 18:08 UTC, Scott Pfister
Details
LineaSDK.dll (22.50 KB, application/octet-stream)
2011-09-15 11:38 UTC, Scott Pfister
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Scott Pfister 2011-09-14 18:08:13 UTC
Created attachment 374 [details]
project that demonstrates the issue -- libLineaSDK.a not included

Please see support emails entitled: 'Getting inexplicable System.TypeLoadException when using ---gcc_flags optional mtouch arguments'
Comment 1 Sebastien Pouliot 2011-09-15 09:06:15 UTC
I might be able to reproduce this without the libLineaSDK.a native library but I need the LineaSDK.dll binding assembly to build the solution.
Comment 3 Scott Pfister 2011-09-15 11:38:48 UTC
Created attachment 380 [details]
LineaSDK.dll

Sorry for the delay! This is the LineaSDK.dll generated from http://github.com/chrisbranson/monotouch-bindings.git, and the same one that I used in this project.
Comment 4 Sebastien Pouliot 2011-09-15 11:48:04 UTC
I could duplicate the issue without the .dll and the .lib - so this is unrelated to the LineaSDK (I renamed the bug).

As soon as "--gcc_flags" is used the exception is throw by the application. Even if using only --gcc_flags="-ObjC" or --gcc_flags "-L${ProjectDir}".

The managed linker is set to "Don't link" and this occurs with the simulator (not tried with a device yet) so it's not MonoLinker nor AOT-related.
Comment 5 Sebastien Pouliot 2011-09-15 14:43:41 UTC
I found this root issue (warning: brain dump follows).

To speed up development the default simulator builds uses a shared 'simlauncher-4' and symlinks to assemblies. In particular it means using 'mscorlib.dll' [1] instead of 'mscorlib-runtime.dll' (which is used by devices and other, non-default. simulator builds).

The two versions exists because:
a) the compiler (and tools) needs a full 'mscorlib.dll' that includes System.Reflection.Emit (SRE)
b) the runtime (on device) cannot uses SRE so having a "smaller" version is helps both:
   b.1) size-wise, it allows smaller applications; and
   b.2) to catch SRE usage inside applications

Sadly the current simlauncher-4+symlink optimization breaks (b.2) because it provide features (SRE/JIT) that are not available in devices.


Back to this bug, using --gcc_flags is not compatible with the shared "simlaucher-4" optimization so a "full" build is done, which brings the correct 'mscorlib-runtime.dll' into the application (it's renamed to mscorlib.dll but it's not the same). That cause Newtonsoft.Json.MonoTouch.dll to break (since it depends on SRE) and throw the TypeLoadException. 

I guess Newtonsoft.Json.MonoTouch.dll can *sometime* work, on devices, when the managed linker (Mono.Linker) is used and *when* it can eliminate the uses of System.Reflection.Emit.*


Now let's see how we can fix (b.2) so this situation cannot occur again and how we can work around Newtonsoft.Json.MonoTouch.dll


[1] lrwxr-xr-x  1 sebastienpouliot  staff       50 15 Sep 14:21 mscorlib.dll -> /Developer/MonoTouch/usr/lib/mono/2.1/mscorlib.dll
Comment 6 Sebastien Pouliot 2011-09-15 16:06:38 UTC
The symlink'ing will be fixed to refer to mscorlib-runtime.dll. This means that the behavior will be identical between using --gcc_flags or not - no more surprise.

Sadly it also means both behaviors fails "as-attached". However I was surprised that, when compiled for devices with the default "Link SDK assemblies"*, the application works (as-in don't throw anything). Took me a while (looking eveywhere but the right place ;-) but I found out that your Newtonsoft.Json.MonoTouch is configured differently for iPhoneSimulator and iPhone.

The good news is that if you change the configuration of iPhoneSimulator to match iPhone it will works. i.e. iPhoneSimulator "Define Symbols" should be "DEBUG;MONOTOUCH;NET35;SILVERLIGHT". 

Could you confirm me that this solve your issue (since my test case evolved a bit from yours) ?

* However the application will throw EngineExecutionException, from Newtonsoft.Json.MonoTouch.dll, if not linked (i.e. "Don't link") but that's likely related to bug #587.
Comment 7 Scott Pfister 2011-09-15 17:20:47 UTC
Yes, this does seem to solve the problem! 

Most interesting -- so there is a real issue with the symlink'ing, but my issue was more closely related to the inconsistent preprocessing compilation symbols (e.g. the missing 'SILVERLIGHT' def in the iPhoneSimulator config) in Newtonsoft.Json.Monotouch? 

Thanks much for the solution!
Comment 8 Sebastien Pouliot 2011-09-15 19:10:43 UTC
Great! :-)

Symlink'ing the "full" mscorlib.dll allowed a bit too much things, like your Newtonsoft.Json.Monotouch build to succeed - which in turn made it much harder to diagnose the real (config) issue.  Sometimes there is unwanted synergy between small bugs, at least when you look for a single one ;-)