Todd Vierling writes:

[snip lots]

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

I dont understand. Doesn't it solve the original question?


>Not quite.  You forgot to address how binary pkgs are known to be useable
>across a given ${MACHINE_ARCH} 

Really? As it stands, they aren't.  (Nor are install sets.)
Isn't that what we're disagreeing about?

And at least for release(7), I think we want all three of
mipsel/mipseb/mips, so that mips-arch headers and manages can be
shared.


>- or how ${MACHINE_ARCH} could be used to
>uniquely identify a given binary.    ``Historical precedent'' or not, it's
>_actively_ used for that.

Where, though?  Can you give me some examples?  How do we fix it so
they aren't? If it's toolchain programs, then should be _the same_
program for both mipseb and mipsel (on any given CPU) with runtime
flags to select the endian-ness.


>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.

Nope. At least at compile-time, the mips _software_ in our tree has
been coded so that it's all ambi-endian: the same source code is used
for memory-copy and memory-move on both mipseb and mipsel. 

There are a few ifdefs to handle this (making {ntoh,hton}{h,l} a no-op
on big-endian). Most of it falls out by #ifdef'ing endian-independent
macros for the unaligned-byte load/store instructions.

Which one gets selected is controlled by the CPP predefines in the
toolchain. Which we can (or should be able to) toggle with a single
commandline qualifier.  (historical practice for mips toolchains and
software since they first shipped.)
AFAICT, the rest is handled at install time (or at compile/config
time, for the toolchain default vector).

Can you give some examples of what this breaks? I still dont get it.