On Thu, 23 Jul 1998, Jonathan Stone wrote:

: That doesn't answer my question, Todd.  The "binary formats" are all
: different insofaras they have different ELF tags. No more and no less
: different than sparc v8 vs 64-bit sparc v9.

However, our sparc64 platform doesn't at current use a 64-bit V9 format - it
uses "v8plus" if you really want those V9 insns, which is a 32-bit file
format.

: >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.
: 
: The documetnation needs to be fixed, then.  

: Nobody disagrees that we need to distinguish both MACHINE_ARCH and
: MACHINE_ARCH_ENDIAN (or whatever it ends up being called).

How far are we going to take that?  If we collimate different byte-ordera
and different bitsizes under one ${MACHINE_ARCH}, then a lot of stuff out
there will have to start checking *three* places to find out just what kind
of binary format is in use.  That's bogus.

What does collimating the MACHINE_ARCH to one name *gain* you?

:  All I'm saying is that we *agreed* that leaving MACHINE_ARCH alone,
                          ^^
Who?  I'd like to read the original thread, since I never saw that.  And why
was it never documented?

: There's one set of kernel support, one toolchain, and it's all kept in
: step across mipsel and mipseb.  Just as it is for m68k. Despite the
: fact that there's 040 instructions that won't run on an 030/020, and
: vice-versa. Does that make them different MACHINE_ARCHes?

No, because you can run '020 bins on an '040 processor - there is a one-way
compatibility.

You can NOT run LE bins on a BE processor, or vice versa.

: >Then why does the pkg system rely on the same promise?  
: 
: Because it hasn't been upgraded to reflect the new promise?
: And (again) _where_ does it use it?

${MACHINE_GNU_ARCH} sets an explicit GNU architecture name.

Binary pkgs use ${MACHINE_ARCH} to differentiate binary formats.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)