The proposal I made for Jonathan's OBJ_ARCH idea has met with mild approval,
so let's see if I can clean it up a bit and make it clearer.  Carbon copied
to the pkg folks and port-mips list, who will be affected by this.  PLEASE
DIRECT REPLIES EITHER TO ME OR TECH-TOOLCHAIN; thanks.

For those who read the last one, there are a couple changes at the bottom.

Background:  The mips platforms are using "mips" as the value for
MACHINE_ARCH on both little and big endian, 32-bit, platforms thus far,
rendering MACHINE_ARCH useless as a unique binary compatibility identifier.
Fortunately, this will not break with 1.3.x releases as newsmips has no
1.3.x release.

=====

Define MACHINE_OBJ_ARCH as an identifier that specifies a unique set of CPU,
architecture, and toolchain criteria from the _default_ output of the
toolchain:

- the processor architecture, such as mips or m68k
- the object file format (a.out, ELF32, ELF64, ECOFF)
- the least common denominator processor (for example, m68k = MC68020)
- the endianness of the processor, if it supports multiple endiannesses
- the basic set of integer and pointer sizes

=====

With that defined, here's how I propose MACHINE_OBJ_ARCH be implemented:

- MACHINE_OBJ_ARCH will be the identifier used in NetBSD documentation to
  describe the type of binaries used on a given system, unless the binaries
  are machine-specific.  (This proposal is intended to make machines of a
  MACHINE_OBJ_ARCH share release sets as well, excepting kernel.)

- Unless otherwise changed, it will be equal to the current value of
  MACHINE_ARCH.  This is in the interest of simplicity.
  Exceptions:  mips splits into mipseb and mipsel, and the sparc64 port
  becomes sparc64 if it changes to a native 64-bit object format before
  release.

- A machine may be capable of running binaries for more than one
  MACHINE_OBJ_ARCH just like any other COMPAT_ emulation, with a correctly
  populated /emul tree.  There is no provision for hard-coding a list of
  emulated MACHINE_OBJ_ARCHs, though there may be compatibility pkgs made
  for them.  (Example:  running 32-bit binaries on a 64-bit system.)

- A change in the MACHINE_OBJ_ARCH will happen when a new architecture
  intrinsic (binary format, endianness, integer/pointer size) is introduced
  in a new port but the MACHINE_ARCH is still the same.

- When a new MACHINE_OBJ_ARCH is created, the different port will use a new
  MACHINE_OBJ_ARCH, but the old MACHINE_OBJ_ARCH will _not_ change its name
  to look aesthetically similar.

- The value will be available for scripts to choose the proper architecture
  via "sysctl hw.obj_arch" and "uname -o".  (This is the reason for the
  previous condition:  it must remain the same as long as the object format
  remains the same.)

- NetBSD's make (Pmake) program will include a definition of
  MACHINE_OBJ_ARCH such that NetBSD builds may use it in Makefiles directly.

- All machines in the same MACHINE_OBJ_ARCH will use an identical toolchain.
  However, the toolchain may contain alternate build targets or binary
  format conversion tools useful only for some of the machines in a
  MACHINE_OBJ_ARCH.

- GNU autoconf changes:
  * Each MACHINE_OBJ_ARCH will have a corresponding MACHINE_GNU_ARCH,
    a one-to-one mapping to ensure uniqueness, useable in the rules below.
    For the most part, these are the same.
  * Configure scripts will accept MACHINE_GNU_ARCH*-*-netbsd as a valid
    identifier for a given OBJ_ARCH.  No script should depend on the
    "manufacturer" field to define any architecture intrinsics.
    (Exception:  GNU autoconf scripts will remap mips-dec-netbsd to
    mipsel-unknown-netbsd for compatibility.)
  * These GNU autoconf changes will be applied to the NetBSD source in-tree
    (src/gnu/dist) as well as GNU pkgs, and appropriate code changes for
    autoconf will be sent back to the FSF for inclusion in the next autoconf
    release.

- NetBSD Foundation released binaries bearing the MACHINE_OBJ_ARCH tag will
  conform to the least common denominator processor for that
  MACHINE_OBJ_ARCH, using the default toolchain output.

- A toolchain format change, such as a.out->ELF, requires a change of
  MACHINE_OBJ_ARCH, as compatibility requires the appropriate shared loader
  and shared libraries.

- The ONLY_FOR_ARCHS rule in pkg Makefiles will continue to use
  MACHINE_ARCH, and not MACHINE_OBJ_ARCH.

- For pkg system compatibility, MACHINE_OBJ_ARCH will be the same as
  MACHINE_ARCH for 1.3.x systems by checking whether or not Pmake sets the
  MACHINE_OBJ_ARCH variable.  That means that pmax is "mips" for 1.3.x pkgs,
  and "mipsel" for 1.4+ pkgs.

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