All of lore.kernel.org
 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 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.