----- Original Message -----
From: "Jay Carlson" <email@example.com>
To: "Ralf Baechle" <firstname.lastname@example.org>; "Jay Carlson" <email@example.com>
Cc: <firstname.lastname@example.org>; <email@example.com>; "Mike Klar"
Sent: Saturday, October 14, 2000 12:11 PM
Subject: RE: stable binutils, gcc, glibc ...
> > RALF: Do your softfp patches somehow cause problems with hardware fp
> > RALF: If not we could throw all things together.
> No, no problems at all. They're just conditional on __HAVE_FPU__.
> submitted for the 2.0.6 branch.
> I'm not really the head toolchain builder for linux-vr these days---Mike
> Klar has a set of unified patches he's been working on.
I would prefer to use mipsel tools and libraries from SGI and have the
linux-vr-specific stuff go away (with linux-vr just mirroring the SGI
> Could somebody who already has signatures on file with the FSF add
> softfloat for mips-linux targets? I mean, we (linux-vr) *think* we're
> to be switching over to the FP emulator soon, but it hasn't happened yet.
> Adding multilib is pretty harmless---I can't think of how it could screw
> the build for hardfp machines.
> The biggest reason I can think of *not* to make such a change is because
> there are already plans in the works to create a mipselnofp-linux target
> more closely describe the situation. But I don't see any momentum behind
> it, and I'd rather have either multilib or mipselnofp than the default
> of "linux-vr must ship patches and maintain separate .debs and .rpms that
> contain a proper superset of mainline functionality".
I think that optimal for me would be if the tools from SGI worked for both
hard-float and soft-float, and we didn't have any linux-vr-specific tools.