On Mon, 4 Feb 2002, James Chacon wrote:

> Did you upgrade your native toolchain already? If so you'll need to bootstrap
> a new one (with supprting libc routines) or revert to an older working one.

Did something happen in the last few minutes? The routines to support
gcc's use of floatx80 on m68k don't seem to exist in my sources (yet,
I think I see where to add them now).

> At this point it sounds like you have a divergent install of libs vs. compiler
> and nothing will easily fix that wihtout syncing them up. build.sh makes a
> large assumption that the host tools can compile code without errors.

I don't understand. What do I need to revert so that "gcc" goes back
to not using floatx80 types? And how will that help, in the long run,
if there is no floatx80 support in libc?

> >On Mon, 4 Feb 2002, James Chacon wrote:
> >
> >> These sounds like generic gcc support routines that should be in the general
> >> library.
> >>
> >> See libc/arch/m68k/gen for the others already in there.
> >
> >I see. That looks do-able.
> >
> >> >mac68k-new-toolchain has a similiar problem building "lint1", except
> >> >that the missing symbols are for extended double precision conversions,
> >> >rather than quad conversions (__fixunsxfdi, __floatdixf, __fixxfdi).
> >> >This breaks the tools build. Curiously enough, a 1.5.1/i386 hosted
> >> >build only calls on __fixunsxfdi, which it finds it in it's own libc
> >> >fine (though I sure don't see where it's coming from).
> >> >
> >> >There's code already in libc/softfloat/softfloat.c for the last two
> >> >conversions, int64_to_floatx80() and
> >> >floatx80_to_int64_round_to_zero(), they're just not respected by
> >> >"softloat-for-gcc.h".
> >
> >What about "./build.sh -t"? We don't want to add libc to the
> >toolchain, do we? Is there an easy way to make gcc compile "lint1"
> >without resorting to floatx80?
> >
> >Frederick
> >
> >
> >
> >
> >
>
>

Frederick