[m-dev.] Remove managed C++ support from Mercury

[Fergus Henderson]

On 06-Oct-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> On Tue, Oct 07, 2003 at 12:15:51AM +1000, Fergus Henderson wrote:
> > On 06-Oct-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > > I've just tried to use the .NET grades with v1.1 of the framework and it
> > > no longer compiles anymore and every error that I have gotten so far is
> > > due to the Managed C++ stuff.
> > >
> > > I suggest that we start to phase out the support for MC++ directly in
> > > Mercury as it has always been the most brittle part of the .NET
> > > implementation.
> > 
> > I'm not sure that it's fair to describe the MC++ support as "brittle".
> > Are the problems that you are encountering due to bugs in the Mercury
> > compiler's MC++ support, bugs in MC++ itself, changes in MC++,
> > or merely due to changes in the .NET Framework library that this MC++
> > code is using?
> > 
> > If, as I suspect, it is the last of these, then it would be wrong to
> > describe the problem as being due to the "brittleness" of the MC++ support.
>
> The two problems I have encountered so far are:
>     * runtime/mercury_mcpp.cpp no longer compiles, I get the link error
>         LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol
>           _main referenced in function _mainCRTStartup
>         mercury_mcpp.dll : fatal error LNK1120: 1 unresolved externals

That looks like it is being compiled/linked with the wrong options,
causing the linker to try to link it as a program with main().

This in is probably due to the odd options that we compile it with.
The right option probably ought to be "/clr:noAssembly", but that
didn't work with 1.0, so we used "/link /noassembly" instead.

The reason for the need for special options was that we are calling
a native code library function, putenv().

> I don't mind leaving it in, but I think that we would save ourselves and
> our users a lot of grief by not allowing MC++ to be directly embedded
> into Mercury.

I must respectfully continue to disagree on this point.

> If a user needs to use some of the features of MC++ they
> can still write an assembly that does what they want and it can still be
> consumed from Mercury.

Sure... but that is often a lot less convenient!
Especially since we still don't yet have a tool that takes .NET assemblies
and generates Mercury interfaces for them.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "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.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------