Subject: Re: MACHINE_ARCH on mips
To: Todd Vierling <tv@pobox.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-mips
Date: 07/25/1998 13:31:39
Todd Vierling writes:

>On Sat, 25 Jul 1998, Jonathan Stone wrote:

>: Same if I compile up an m68k userland for an Amiga or DraCo or the VME
>: multiprocessor modules in my lab, using the optimal O40-or-better
>: insns (dcas? mov16?).  I haven't changed the ``default'' for that
>: toolchain, but I've built an entire luserland that needs an 040/060.
>
>See below.  This is not the same argument.

No, as far as I can see, it's _exactly_ the arguement you used :->.


>It doesn't matter what people always use:  it matters that the least common
>denominator, the default toolchain output of a MACHINE_ARCH, is consistent
>and runs on a given MACHINE_ARCH.

You're assuming your conclusion.  That's a circular argument.


>: You assume a tight identity between "will this run"?  and
>: $MACHINE_ARCH, but that just doesn't exist.
>
>It exists, and is being used in
>
>- GNU autoconf

No, it *doesnt*. It uses similar names from an _internal_ namespace.
They are _not_ the same as the results of `uname -m` or anything else,
except by coindidence or shared design choices.  And ${MACHINE_ARCH}
or `uname -m` is not used directly in the diffs I've been sending back
to Ian.  Any more than "RISC" is, for mips ultrix systems.

Todd, please dont keep saying things that are factually untrue.


>- pkgs (documented, and tightly used)

All this says to me is that the pkg people made an assumption that
turns out to be incorrect.  (Just like the initial (FreeBSD?) design
assumption that all ports use a.out, and then that the only ELF port
was alpha.).  

And if it needs fixing for binary pkgs, it can be fixed in the same
way that it's been fixed in autoconf. Sheesh.