Subject: Re: MACHINE_ARCH on mips
To: Todd Vierling <tv@pobox.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-toolchain
Date: 07/25/1998 11:44:38
: Splitting $MACHINE_ARCH doesn't buy much [snip]

>It actually keeps configuration more uniform.  Paricularly if you can match
>on "mips*" when endianness is not an issue (which is done in autoconf now, I
>believe).

But, we can _still do that_.  Look at how autoconf handles mips
Ultrix.  On mips Ultrix, uname -m returns "RISC".  ISTR that on SGIs,
it returns "mips".  autoconfig handles htiser So we tweak about 4
lines of autoconf sh code to check for "netbsd" and "mips", and if so,
set the autoconf "architecture" to "mipsel" or "mipseb", just like it
does for IRIX or Ultrix.

All the rest of the autoconfigure code can still match on mips*-*-* or
mipsel*-*-* or mipseb*-*-*.  Just like it does now.  That's why GNU
autoconfigure _has_ those internal names.


>And, of course, no matter the outcome, the output of `uname -m` needs to be
>separate between the two.  This is the long-standing traditional way of
>selecting a set of binaries for a given platform that supports more than one
>CPU architecture, and is well known outside of NetBSD.

I dont find that compelling.  Didn't 4.4bsd ship with uname -m
returning "mips" on both pmax and SONY News?

I mean, if this script is for NetBSD, it needs to DTRT (whatever that
is), and if it's for an vendor OS being run under emulation (acroread
scripts? mathematica?), we need to fudge uname appropriately for the
vendor OS ("mips" or "RISC" or whatever).  Right?

I feel uneasy about having ${MACHINE_ARCH} and uname -m returning
different values. And last time we went over this -- which was for
toolchain internal defines!-- we decided to leave ${MACHINE_ARCH}
alone.

Maybe there's no really good solution here.