Subject: re: IMPORTANT: MACHINE_ARCH WRONG ON MIPS PLATFORMS
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Todd Vierling <firstname.lastname@example.org>
Date: 07/23/1998 16:38:11
On Thu, 23 Jul 1998, Jonathan Stone wrote:
: Please think through this. I think MACHINE_ARCH == mips is a better
: decision. not going to change my mind by repeating the same arugments.
: mipsel vs mipseb is no bigger a deal than mips32 vs mips64. THink
: about it. should those show up as different kinds of $MACHINE_ARCH
Yes, unless it has the same binary sets.
The MACHINE for sparc64 is sparc64, but the MACHINE_ARCH is sparc, becasue
the binary format is the same unless you're using V9 instructions (similar
to using 68060 instructions on m68k) - 32-bit a.out, SPARC V8 big-endian by
: My take is that $MACHINE_ARCH used to lump together two concepts: both
: ``mips'' (all endianness vs, say, ``m68k'' and `mipseb'' versus ``mipsel''
: (and soon mips64 vs mips32?).
If mips64 will require a different binary format, it to should be a
different MACHINE_ARCH as well.
: But there are still a lot of meaningful distinctions that get made
: based on purely the _architecture_: e.g, in building set-list entries
: which depend on the fact that a machine is a "mips", irrespective of
This works only because we _happen_ to use the same basic toolchain format
(ELF) on mipsel and mipseb. If one of them were still a.out, this rgument
would go out the window.
: We need to have two levels of distinction. That much everyone agrees on.
: I'm saying it makes more sense to leave MACHINE_ARCH==mips alone, and
: introduce a new way to name and specify the endian-ness. And (as best
: I recall) that was also the final decision last time it came up. OK?
Pkgs care less about endianness. Third party software cres less about
MACHINE_ARCH SHOULD SPECIFY A COMPATIBLE SET OF BINARIES, AND IS DOCUMENTED
TO DO SO. That's a far more long-standing promise than the mips platforms
have even existed.
MIPS is broken.
: >we're using it now, and we probably will continue to be using it
: >that way. The existing state is breaking that promise that MACHINE_ARCH
: No, as best I recall, we changed the promise.
Then why does the pkg system rely on the same promise? Why does GNU
-- Todd Vierling (Personal email@example.com; Bus. firstname.lastname@example.org)