From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Jay Carlson" <nop@nop.com>, "Ralf Baechle" <ralf@oss.sgi.com>
Cc: <linux-mips@fnet.fr>, <linux-mips@oss.sgi.com>,
"Mike Klar" <mfklar@ponymail.com>
Subject: Re: stable binutils, gcc, glibc ...
Date: Sat, 14 Oct 2000 12:29:33 -0400 [thread overview]
Message-ID: <005e01c035fb$ef883b40$0701010a@ltc.com> (raw)
In-Reply-To: KEEOIBGCMINLAHMMNDJNEECBCAAA.nop@nop.com
----- Original Message -----
From: "Jay Carlson" <nop@nop.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>; "Jay Carlson" <nop@place.org>
Cc: <linux-mips@fnet.fr>; <linux-mips@oss.sgi.com>; "Mike Klar"
<mfklar@ponymail.com>
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
machines?
> > RALF: If not we could throw all things together.
> No, no problems at all. They're just conditional on __HAVE_FPU__.
Consider
> ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
> 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
stuff).
> Could somebody who already has signatures on file with the FSF add
multilib
> softfloat for mips-linux targets? I mean, we (linux-vr) *think* we're
going
> 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
up
> 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
to
> 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
case
> 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.
Regards,
Brad
WARNING: multiple messages have this Message-ID (diff)
From: "Bradley D. LaRonde" <brad@ltc.com>
To: Jay Carlson <nop@nop.com>, Ralf Baechle <ralf@oss.sgi.com>
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com,
Mike Klar <mfklar@ponymail.com>
Subject: Re: stable binutils, gcc, glibc ...
Date: Sat, 14 Oct 2000 12:29:33 -0400 [thread overview]
Message-ID: <005e01c035fb$ef883b40$0701010a@ltc.com> (raw)
Message-ID: <20001014162933.PxyyyOY5fKdgdy1jwBl45t5vG7-MkKsZ_HmakHlCrU4@z> (raw)
In-Reply-To: KEEOIBGCMINLAHMMNDJNEECBCAAA.nop@nop.com
----- Original Message -----
From: "Jay Carlson" <nop@nop.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>; "Jay Carlson" <nop@place.org>
Cc: <linux-mips@fnet.fr>; <linux-mips@oss.sgi.com>; "Mike Klar"
<mfklar@ponymail.com>
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
machines?
> > RALF: If not we could throw all things together.
> No, no problems at all. They're just conditional on __HAVE_FPU__.
Consider
> ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
> 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
stuff).
> Could somebody who already has signatures on file with the FSF add
multilib
> softfloat for mips-linux targets? I mean, we (linux-vr) *think* we're
going
> 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
up
> 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
to
> 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
case
> 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.
Regards,
Brad
next prev parent reply other threads:[~2000-10-14 16:27 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-14 5:13 stable binutils, gcc, glibc Jun Sun
2000-10-14 3:55 ` Ralf Baechle
2000-10-14 4:21 ` Ralf Baechle
2000-10-14 10:57 ` Florian Lohoff
2000-10-14 14:51 ` Jay Carlson
2000-10-14 14:51 ` Jay Carlson
2000-10-14 15:09 ` Ralf Baechle
2000-10-14 16:11 ` Jay Carlson
2000-10-14 16:11 ` Jay Carlson
2000-10-14 16:29 ` Bradley D. LaRonde [this message]
2000-10-14 16:29 ` Bradley D. LaRonde
2000-10-16 0:35 ` Ralf Baechle
2000-10-16 1:33 ` Mike Klar
2000-10-16 1:33 ` Mike Klar
2000-10-16 11:26 ` Jay Carlson
2000-10-16 11:26 ` Jay Carlson
2000-10-16 11:30 ` Ralf Baechle
2000-10-16 12:00 ` Ralf Baechle
2000-10-18 1:59 ` Jay Carlson
2000-10-18 1:59 ` Jay Carlson
2000-10-18 20:31 ` Ralf Baechle
2000-10-14 16:11 ` Jay Carlson
2000-10-14 16:11 ` Jay Carlson
2000-10-14 16:12 ` Ralf Baechle
2000-10-14 16:22 ` Bradley D. LaRonde
2000-10-14 16:22 ` Bradley D. LaRonde
2000-10-14 23:47 ` Keith Owens
2000-10-16 1:07 ` Ralf Baechle
2000-10-16 7:00 ` Alan Cox
2000-10-16 7:00 ` Alan Cox
2000-10-14 10:55 ` Florian Lohoff
2000-10-14 12:41 ` Ralf Baechle
[not found] ` <Pine.LNX.4.21.0010140730280.17430-100000@spawn.hockeyfiend.com>
2000-10-14 14:25 ` Ralf Baechle
2000-10-14 17:54 ` Florian Lohoff
2000-10-16 15:41 ` Maciej W. Rozycki
2000-10-18 4:04 ` The initial results (Re: " Jun Sun
2000-10-18 1:33 ` Florian Lohoff
2000-10-18 9:20 ` Jun Sun
2000-10-18 2:25 ` nick
2000-10-18 9:18 ` Florian Lohoff
2000-10-18 12:27 ` Ralf Baechle
2000-10-18 1:57 ` Ralf Baechle
2000-10-18 12:30 ` Florian Lohoff
2000-10-18 22:37 ` Ralf Baechle
2000-10-18 11:42 ` Geert Uytterhoeven
2000-10-18 17:15 ` Jun Sun
2000-10-20 14:55 ` Geert Uytterhoeven
2000-11-06 11:43 ` Jay Carlson
2000-11-06 11:43 ` Jay Carlson
2000-10-20 11:09 ` Andreas Jaeger
2000-10-20 12:03 ` Jay Carlson
2000-10-20 12:03 ` Jay Carlson
2000-10-21 1:24 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='005e01c035fb$ef883b40$0701010a@ltc.com' \
--to=brad@ltc.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.sgi.com \
--cc=mfklar@ponymail.com \
--cc=nop@nop.com \
--cc=ralf@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.