An update on the status of DotGnu/Mono and the Mercury IL backend. I have tried the patches with both DotGnu and Mono on Win32, and also with Mono on Linux (DotGnu is already being covered by Julien on Linux). Both DotGnu and Mono have a C# compiler (cscc/mcs), a IL compiler (ilasm) and a linker (ilalink/al). Neither have a Managed C++ compiler, which we'll have to look into after we convince the C# to compile. It can probably be cut out as unnecessary. DotGnu does not have the /addmodule: option to cscc, but instead it has a -fmodule= option. mcs supports all Microsoft csc type flags, as well as GNU type flags (eg. /addmodule: and -addmodule and --addmodule) DotGnu fails to build because it cannot find the mercury namespaces (eg. mercury.runtime.*). Mono crashes completely with the following error messages: ** (C:/Programs/Programming/Mono-<a href="http://1.1.12.1/lib/mono/1.0/mcs.exe:2312"> 1.1.12.1/lib/mono/1.0/mcs.exe:2312</a>): WARNING **: The following assembly referenced from C:\cygwin\installs\mercury-compiler-0.12.2\tmp_dir\library\bool.dll could not be loaded: Assembly: mercury (assemblyref_index=0) Version: <a href="http://0.0.0.0">0.0.0.0</a> Public Key: 228c167d12aa0b0b The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (.). ** (C:/Programs/Programming/Mono-<a href="http://1.1.12.1/lib/mono/1.0/mcs.exe:2312">1.1.12.1/lib/mono/1.0/mcs.exe:2312</a>): WARNING **: The class mercury.bool.bool_0 could not be loaded, used in mercury, Version= <a href="http://0.0.0.0">0.0.0.0</a>, Culture=neutral, PublicKeyToken=228c167d12aa0b0b This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Obviously it is unable to realise that it is in the middle of building the mercury assembly it is referencing. Both Mono and DotGnu ilasm appear to try to build assemblies rather than modules, so that MS csc complains that it should reference the resultant DLLs rather than including them. I tried building the IL library with MS ilasm to see if this was the problem, but the same errors occurred in cscc/mcs. The problem appears to be that neither them are able to find the namespace or the assembly mercury, as it is in the middle of being built. Any suggestions as to what to do next? Jon