On Thu, 23 Jul 1998, Jonathan Stone wrote:

: The right fix is that we build bi-endian toolchains for mips, so that
: we can compile for mipsel on a mipseb with the "native" toolchain, and
: vice-versa. so we'd always configure

That "fixes" the bfd stuff.  But I never said anything against it; some
platforms (m68k, sparc, i386) now build an ELF-capable toolchain.

: The reason we don't is that FSF/Cygnus codebase still thinks that
: mipsel == mips-dec-* (pmaxes are the only little-endian mips), and all
: other mips are big-endian.  Once we fix that, most of the problems
: you're asking about go away.

Not quite.  You forgot to address how binary pkgs are known to be useable
across a given ${MACHINE_ARCH} - or how ${MACHINE_ARCH} could be used to
uniquely identify a given binary.  ``Historical precedent'' or not, it's
_actively_ used for that.

: >Regardless of the chip involved, a little endian system and a big endian
: >system are _not_ the same architecture.
: 
: Huh?  CPUs of the same chip type or family *are* of the same
: architecture.  That's what computer ``architecture'' means!

An architecture is described by both its hardware and its software.  In most
cases, programs that care about the difference are caring about the
_software_ architecture.

MACHINE_ARCH is currently used to define a software and hardware
architecture.  That means the current definition of "mips" is broken.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)