Re: Mercury ILDasming was ([DotGNU]Mercury on Portable.NET (not successful))

[Fergus Henderson]

On 03-Mar-2003, James Michael DuPont <address@hidden> wrote:
> > The use of C string literals is also unnecessary and undesirable --
> > all we are using them for is to construct .NET strings, so we might
> > as well use the .NET string literal syntax (S"..."), rather than
> > using C string literals and then converting them to .NET strings.
> > I think that too was originally done to work around a bug in an early
> > beta version of MSVC++.NET.  I will modify the Mercury standard
> > library
> > sources to avoid that.
> ok
> rhys will have to help you with that.

It's OK, I can do that one all by myself, thanks ;-)
In fact the fix for that is already checked in to the
Mercury CVS repository; when I've fixed the `_fltused'
problem as well, I'll produce some updated DLLs for you.

> Here are the unresolved namespaces : 
> Diagnostics
> VisualC
...
> token 0x0A000006: member
> `Microsoft.VisualC.DebugInfoInPDBAttribute..ctor' not found
> `Microsoft.VisualC.MiscellaneousBitsAttribute..ctor' not found

This is some gunk that MSVC++ generates references to for programs
compiled with debugging enabled.  It should be fine to just provide
stub implementations of those.

> token 0x0A00005A: member `System.Diagnostics.Process.Start' not found
> token 0x0A00005B: member `System.Diagnostics.Process.WaitForExit' not
> found
> token 0x0A00005C: member `System.Diagnostics.Process.get_ExitCode' not
> found

These are needed for invoking system commands.

> token 0x0A000003: member
> `mercury.array__cpp_code.mercury_code.special___Unify___array_1_0' not
> found

That one is defined in array__cpp_code.dll in the DLLs that I put up.
So I'm not sure why it isn't being found.  Perhaps a bug in Portable.NET?
Perhaps a mismatch in the argument types or the return type?
(In which case it would help if the error message was more informative.)

Ah, yes, I see now -- it is a mismatch in the return type.
This is a bug in the Mercury implementation.
Again, it doesn't show up on the Microsoft.NET implementation
because the procedure in question never gets called.

Looking at the remaining errors you posted,
they look like they are all going to be similar issues.

Since the Microsoft.NET implementation accepts programs like this,
it might be nice to only issue a warning if the program contains
undefined symbols, rather than a link error, and to then report
an error at run-time if the symbol is actually used.

-- 
Fergus Henderson <address@hidden>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.