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

-- 
-----------------------------------------------------------------
[EMAIL PROTECTED]                                     debian/rules
[EMAIL PROTECTED]                             Monkeys do it better
_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to