[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mercury ILDasming was ([DotGNU]Mercury on Portable.NET (not successf
Re: Mercury ILDasming was ([DotGNU]Mercury on Portable.NET (not successful))
Mon, 3 Mar 2003 20:01:04 +1100
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.
> 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 :
> 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
> token 0x0A00005C: member `System.Diagnostics.Process.get_ExitCode' not
These are needed for invoking system commands.
> token 0x0A000003: member
> `mercury.array__cpp_code.mercury_code.special___Unify___array_1_0' not
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.