Subject: Re: borken state of quad/soft float on sparc64
To: Frederick Bruckman <firstname.lastname@example.org>
From: James Chacon <email@example.com>
Date: 02/04/2002 16:09:48
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.
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.
>On Mon, 4 Feb 2002, James Chacon wrote:
>> These sounds like generic gcc support routines that should be in the general
>> 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
>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?