Bug 6997 - Corlib not in sync with this runtime: expected corlib version 96, found 633.
Summary: Corlib not in sync with this runtime: expected corlib version 96, found 633.
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 5.4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-09-07 15:04 UTC by Michael Bayne
Modified: 2012-09-07 18:48 UTC (History)
2 users (show)

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

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:

Description Michael Bayne 2012-09-07 15:04:49 UTC
Upon upgrading to MonoTouch 5.4, I'm no longer able to build IKVM for MonoTouch. You can reproduce the failure easily like so:

% git clone git://github.com/samskivert/ikvm-monotouch.git
% cd ikvm-monotouch
% nant -t:moonlight-2.0

Here's the (first) failing command in all its glory:

% /Library/Frameworks/Mono.framework/Versions/2.10.9/bin/mono \
    --runtime=moonlight --security=temporary-smcs-hack \
    "/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/2.1/smcs.exe" \
    /fullpaths /optimize /nologo "/target:exe" \
    "/out:/Users/mdb/projects/ikvm-monotouch/tools/asmref.exe" \
Corlib not in sync with this runtime: expected corlib version 96, found 633.
Loaded from: /Developer/MonoTouch/usr/lib/mono/2.1/mscorlib.dll
Download a newer corlib or a newer runtime at http://www.go-mono.com/daily.

This "/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/2.1/smcs.exe" looked potentially suspicious, since I figured maybe the MonoTouch smcs.exe would be linked against the correct mscorlib, so I tried this:

% /Library/Frameworks/Mono.framework/Versions/2.10.9/bin/mono \
    --runtime=moonlight --security=temporary-smcs-hack \
    /Developer/MonoTouch/usr/lib/mono/2.1/smcs.exe \
    /fullpaths /optimize /nologo "/target:exe" \
    "/out:/Users/mdb/projects/ikvm-monotouch/tools/asmref.exe" \

and got the same failure.

I will admit to neither being a NAnt expert, nor an expert in the version jockeying needed to get the desktop profile Mono to build IKVM using the Moonlight profile, so that it can be used on MonoTouch, but I've managed to keep things working since MonoTouch 5.1 or so, so I'm pretty sure I was not doing anything too crazy to make it all work. It was working fine with 5.2.13.
Comment 1 Michael Bayne 2012-09-07 15:06:33 UTC
I just thought to try /Developer/MonoTouch/usr/bin/mono which seems to work.

I'll see if I can hack up NAnt's configuration to make it use that when provided with -t:moonlight-2.0. Any advice or clarification on how to do this properly would be greatly appreciated.

Comment 2 Michael Bayne 2012-09-07 15:07:03 UTC
> I just thought to try /Developer/MonoTouch/usr/bin/mono which seems to work.

That's in place of /Library/Frameworks/Mono.framework/Versions/2.10.9/bin/mono in case that wasn't immediately apparent.
Comment 3 Michael Bayne 2012-09-07 15:13:42 UTC
Oh, one more thing. I had added a symlink from /Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/2.1 to /Developer/MonoTouch/usr/lib/mono/2.1 (which of course explains why there's no difference between /Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/2.1/smcs.exe and /Developer/MonoTouch/usr/lib/mono/2.1/smcs.exe).

Anyhow, I'm still trying to get NAnt to use MonoTouch's Mono when running the compiler, to no avail.
Comment 4 Michael Bayne 2012-09-07 16:27:11 UTC
I managed to get NAnt to use the MonoTouch mono thusly:

diff /Library/Frameworks/Mono.framework/Versions/2.10.9/share/NAnt/bin/NAnt.exe.config*
<                         <property name="prefix" value="/Developer/MonoTouch/usr" />
>                         <property name="prefix" value="${pkg-config::get-variable('mono', 'prefix')}" />

However, this leads me into a bit of a quagmire, because really I don't want to compile all of IKVM against the MonoTouch DLLs, I need a more nuanced setup.

IKVM consists of ikvmc.exe which converts Java bytecodes to CLR bytecodes, along with a few DLLs which need to be linked with the target app at runtime to emulate the Java platform classes (the relevant ones in this case being IKVM.Runtime.dll, IKVM.Runtime.JNI.dll, IKVM.OpenJDK.Core.dll, IKVM.OpenJDK.Text.dll and IKVM.OpenJDK.Util.dll). ikvmc.exe makes use of functionality that requires the desktop profile, but the runtime libraries need to be linked against the MonoTouch mscorlib libraries.

Anyway, I need to dig deeper into how to make this all work properly, because clearly whatever I was doing before to make this work has all fallen apart. If there's any info on how the mscorlib linking changed in this latest release that might inform why things worked before and why they don't now, I'd greatly appreciate hearing about it.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2012-09-07 18:13:25 UTC
Your problem is that you are running the mscorlib.dll provided by MonoTouch while using the system mono binary. The reason it worked is pure luck; mscorlib.dll and the mono runtime are tied together very tightly, you should never use the mono runtime from one place with mscorlib.dll from another.

I believe you found the solution yourself (but maybe I don't fully understand your scenario):
* Build ikvmc.exe using mcs.
* Build the ikvm runtime libraries using smcs.

BTW this problem will cease to exist once in the future, when we start using mono 2.12 in MonoTouch instead of mono 2.10, since [s]mcs.exe doesn't use reflection and therefore doesn't need a specific mscorlib.dll either.
Comment 6 Michael Bayne 2012-09-07 18:33:15 UTC
Yeah, as usual the situation is complicated. However, I think I've got something working now, though I'm running into other issues that I need to fix before I can be completely sure.

IKVM does a lot of extra fiddling to ensure that it can use a different version of the core libraries than the one with which it was built (indeed, I think that's why the Mono compiler suite ended up using IVKM's reflection component).

But building IKVM itself requires a lot of intertwingled parts which used to 'just work' (probably by accident, as you explained), and now special care has to be taken. NAnt makes this an extra pain in the ass by dictating that the version of the core libraries used when compiling code is a global switch passed on the command line (-t:moonlight-2.0).

So I've broken the IKVM build process into five phases, which seems to achieve the necessary chicken sacrifice:

Phase 1. Build IKVM.Reflection, ikvmc.exe and ikvmstub.exe against the desktop profile
Phase 2. Build the first pass version of IKVM.Runtime.dll against the moonlight profile
Phase 3. Build a bunch of Java crap and run ikvmc.exe against it (with ikvmc.exe configured to link against the MonoTouch core libraries); this build has to be done against the desktop profile because it builds some command line tools needed for the build and those require the desktop profile (yay!)
Phase 4. Build the real version of IKVM.Runtime.dll against the moonlight profile
Phase 5. Build the ikvm.exe "interpreter" and some other random stuff (the native libraries). The interpreter has to be built against the desktop profile, but it needn't work on MonoTouch as we convert Java to C# long before MonoTouch sees anything.

Anyway, sorry for all the bug comment spam, but it is very surprising to me that I wasn't bitten by this earlier. If you don't mind leaving this issue open until I report back that things are once again fully operational, I'd appreciate it.
Comment 7 Michael Bayne 2012-09-07 18:48:20 UTC
OK, everything looks good. Thanks again!