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. Maybe I could submit a bug report there instead attaching my patch as an illustration of what is happening and what sort of Mono libs build could be helpful for 64bit Mono in Wine?
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.
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.
On 01/21/2016 10:14 PM, Vincent Povirk wrote:
Changes to Mono should ideally be sent upstream. For code generation issues you could add a .il test in mono/tests. This case is sort of complicated because it sounds like the code's validity depends on the architecture. (But that's also worth testing on .NET I guess.)
If we can't get the patch upstream, and it helps Windows apps, then I can maintain a diff in wine-mono.