Frankly I did not intend fixing mono compiler and modifying mono build environment in a way that would look like a good patch to send. I presume it is rather long way to go to get it done and accepted, while I do not deal with .NET/mono in my everyday life.
For loading class libraries, the right solution is to fix Wine so that it can load pure .NET images in non-x86 processes, using the _CorValidateImage hook. That shouldn't require changes to Mono.
It sounded like you had also found a bug in the Mono code generator which could be useful to fix upstream. If you don't want to take the time to get the fix in, maybe you could file a bug with the Mono project containing an example of IL code that triggers it?
Do you think there is any way we can test the current (probably much simpler) VTable issue? I could send, for instance, a prebuilt MSI with these things hotfixed.
I think I have sufficient information now to test this, but I need some time try these things and hopefully catch up with what you've done.
BTW my real application (its .net parts) worked after all these fixes. There is still some crash both in my app and short test on exit from application on mono assembly deinit, but this is likely a quite separate issue and happens in 32 bit also.
Cool. If you have a testcase with source code that triggers the crash on 32-bit, I can look into it. Would you be willing to file a bug for this?