Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: Ben Elliston <bje@redhat.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	"H . J . Lu" <hjl@lucon.org>,
	linux-mips@oss.sgi.com
Subject: Re: PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?)
Date: Tue, 11 Dec 2001 11:30:08 -0200	[thread overview]
Message-ID: <20011211113008.A30693@dea.linux-mips.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0112110939100.17417-100000@hypatia.brisbane.redhat.com>; from bje@redhat.com on Tue, Dec 11, 2001 at 09:40:50AM +1000

On Tue, Dec 11, 2001 at 09:40:50AM +1000, Ben Elliston wrote:

> > > crosscompilation unlike the /proc/cpuinfo thing and doesn't rely on
> > > properly installed libraries and headers might possibly of interest for
> > > building standalone software.
> 
> >  Hmm, I don't think config.guess is ever used for cross-compilation as
> > the script's purpose is to guess the host and you need to specify one
> > explicitly for a cross-compilation to happen.  Anyway it's saner not
> > to use build system properties to guess host system ones.
> 
> You're close, but not quite correct.  In a cross-compilation environment,
> the job of config.guess is to determine the type of the build system,
> which may be different to the host and will certainly be different to the
> target.

In case of Linux/MIPS it could guess wether it's a little endian or big
endian configuration and emit mips-unknown-gnu-linux or
mipsel-unknown-gnu-linux that is taking away the burden of the user knowing
about the right endianess for his target - specifying mips-linux as target
should then be sufficient.  Does that sound sane or would overriding the
users explicitly give targetname (or even hostname for a native build) be
considered a bad thing?

  Ralf

  parent reply	other threads:[~2001-12-11 17:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-06 17:35 Why is byteorder removed from /proc/cpuinfo? H . J . Lu
2001-12-06 17:53 ` H . J . Lu
2001-12-06 17:57 ` Ralf Baechle
2001-12-06 18:36   ` PATCH: Handle Linux/mips (Re: Why is byteorder removed from /proc/cpuinfo?) H . J . Lu
2001-12-06 18:41     ` Ralf Baechle
2001-12-06 18:51       ` H . J . Lu
2001-12-06 19:16         ` Ralf Baechle
2001-12-10  7:23     ` Ben Elliston
2001-12-10  9:42       ` Ben Elliston
2001-12-10 14:21         ` Daniel Jacobowitz
2001-12-10 23:34           ` Ben Elliston
2001-12-10 23:34             ` Ben Elliston
2001-12-11  0:20             ` H . J . Lu
2001-12-11  0:23               ` Ben Elliston
2001-12-11  0:28                 ` H . J . Lu
2001-12-10 18:28         ` Ralf Baechle
2001-12-10 20:24           ` Maciej W. Rozycki
2001-12-10 23:40             ` Ben Elliston
2001-12-10 23:40               ` Ben Elliston
2001-12-11  0:04               ` Maciej W. Rozycki
2001-12-11 13:30               ` Ralf Baechle [this message]
2001-12-11 23:11                 ` Daniel Jacobowitz
2001-12-12  8:07     ` Ben Elliston
2001-12-10 18:40   ` Why is byteorder removed from /proc/cpuinfo? Dominic Sweetman
2001-12-10 19:06     ` 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=20011211113008.A30693@dea.linux-mips.net \
    --to=ralf@oss.sgi.com \
    --cc=bje@redhat.com \
    --cc=hjl@lucon.org \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox