[m-dev.] little bootstrapping problem.

[Tyson Dowd]

On 04-Aug-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 04-Aug-1998, Tyson Dowd <trd at stimpy.cs.mu.oz.au> wrote:
> > The changes I committed today to private_builtin.m won't compile without a
> > new compiler compiling them -- today's compiler generates base_type_*
> > for type_info/1, but there is handwritten code for type_info/1 as well.
> > I've just backed it out for the moment.
> > 
> > What I'm think of to get around this problem is add the hand-written
> > definitions for base_type_* into the runtime.  Since the runtime it is *a*
> > library, the symbols won't clash with those in *the* library (linker
> > will take just the first definition).  But if the library doesn't have
> > the base_type_* symbols in it (stage 2), then it will get them from the
> > runtime.  So stage 2 should compile OK.
> 
> I think that would work OK, so long as you make sure that the
> definitions for base_type_* are in their own object module.
> 
> The alternative is to just wait until the compiler changes have been
> installed on all four of our machines.  That might be a nicer solution
> in the long run.

That won't work, because they compiler won't link without these symbols.

What happens is the stage 1 compiler will link ok (the installed
compiler generates base_type_*), then it will compile stage 2 without
the base_type_* for type_info/1.  Eventually stage 2 will have a link
error and so the test_mercury script will refuse to install the compiler
because it fails to bootstrap.

-- 
       Tyson Dowd           # "Bill Gates is a white persian cat and a monocle
                            # away from becoming another James Bond villan."
     trd at cs.mu.oz.au        # "No Mr Bond, I expect you to upgrade."
http://www.cs.mu.oz.au/~trd #                -- Dennis Miller and Terri Branch