[Mono-list] Mercury on Mono (not successful)

[Paolo Molaro]

On 02/27/03 Fergus Henderson wrote:
> The first one is that Mono doesn't search the GAC.
> OK, that one is easy to work around; just add the appropriate
> directory to the PATH.

Is there a windows developer here? I someone can provide the code
that returns the path to the GAC, I'll add it to the default search path
when running in windows.

> The second one is that Mercury and Mono both define a DLL named "gc.dll".
> Putting the Mercury gc.dll first in the PATH causes `mono' to abort with
> the error message
> 
> 	mono.exe - Application Error
> 
> 	The application failed ot initialize properly (0xc000007b).
> 	Click on OK to termiante the application

This is an issue with the program loader in windows: mono is dynamically
linked to the Boehm GC library, named gc,dll. If the loader finds your
dll, it can't use it for resolving the symbols and aborts the
application. I have no idea how to solve this issue.

> Unfortunately I still got a LOT of warning messages (8,591 of them)
> of the form
> 
> 	** (./hello.exe:3352): WARNING **: Could not load class from token
> 	0x0100002e in C:\cygwin\home\fjh\ws\hermes\samples\mono_test\array.dll
> 	...
> 	... lots more like that ...
> 	...
> 	** (./hello.exe:3304): WARNING **: Could not load class from token
> 	0x01000072 in C:\cygwin\home\fjh\ws\hermes\samples\mono_test\io.dll

Ok, I fixed a couple of issues related to type resolution in my tree.
There are still two issues:
1) in the files you provided a type is referenced, but I could not find
it defined in any module:
	 [mercury]mercury.private_builtin.ref_1
I guess a file is missing from the tarball.

2) references to nested types are encoded with (for example):
	namespace = mercury.list
	name = list_1/[|]_2
I always thought that was not allowed and that you should use a typeref
to the parent with:
	namespace = mercury.list
	name = list_1
and a typeref to the typeref with:
	namespace = 
	name = [|]_2

I guess we'll have to handle also this special case.

> I also tried using the `ilasm' on the IL generated by the Mercury compiler.
> That failed too, with the following error message:

Our ilasm is not yet functional enough for many IL sources.

Thanks!

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better