>I looked into the mips header files and saw a ghastly WRONG thing in there:
>both little-endian and big-endian mips systems have "mips" for MACHINE_ARCH.

>${MACHINE_ARCH} defines a set of binary formats that are uniform across that
>${MACHINE_ARCH}.  For example, all m68k bins are the same format, so they
>all have the same ${MACHINE_ARCH} - m68k.

That's _one_ thing it does.

>Using "mips" for both big-endian and little-endian sets MUST be changed,
>regardless of the effects.  Leaving it as-is will break a lot more than just
>config.bfd - it breaks the entire concept of ${MACHINE_ARCH}-global binary
>sets (not to mention the concept of binary pkgs).
>
>Now, the question is how to do it:  make a new "mipsle," perhaps?


Todd,

This comes up every so often.  I understand completely the invariant
you are trying to keep, and yes, historically that's what
$MACHINE_ARCH} was introduced to mean.  Unfortunately the meaning of
${MACHINE_ARCH} isn't _only_ the things above.  It's also used for
things like ``what kind of toolchain is this'', ``what CPU
architecture is this'', etc,. etc.

There's been opinions both ways on this issue, but IIRC last time it
came up, the consenus was to leave $MACHINE_ARCH as "mips" for
mips-cpu but endian-neutral tests, and endian-neutral mips-cpu set
contents (header files, what else?) but to create "mipsel" and
"mipseb" portions of the release(7).