Jonathan Stone wrote:
> 
> >however, in a couple of years time, i hope we don't wish we went for
> >one such that "netbsd" was (will be) now right...
> 
> less, surely? In 18 months 1.5 will be over a year old, an on most arches,
> a.out NetBSD will be more out of date as 1.3.3 is now. How about
>         <arch>-<vendor>-netbsdNNN-{aout,elf},
> for ports that need  to transition, which can revert  to just
> 
>         <arch>-<vendor>-netbsdNNN
> 
> after 2.1 (i.e., two full releases after 1.5).
> 
> For dynanic tests -- what does libtool do?  Safest is to link a
> hello-world program and use file to test if it's ELF.
> (ELF programs  will include "ELF" in file(1) output

Don't forget that the full tupple is (from config.sub):

# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
#       CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or in some cases, the newer four-part form:
#       CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
# It is wrong to echo any other type of specification.

which accomodates things like i386-pc-linux-gnu and the truly perverse
i386-unknown-netbsd-gnu/linux (which currently isn't accepted by
config.sub. I'll take issue to the autoconf pages :-)

Jason R. Thorpe <thorpej@nas.nasa.gov>:
>
> Personally, I think we should do:
> 
> arch-objformat-netbsd, like:
> 
> m68k-aout-netbsd
> i386-elf-netbsd
> 
> ...I mean, it's not like the "vendor" portion makes any difference
> in NetBSD... So why not make it do something useful?

I suspect this won't get far.  It might be ok as a NetBSD internal name
but not as an official tupple.
For instance, ``i386-linux'' gets mapped onto the approved form
``i386-pc-linux-gnu by config.sub.

A pedantic interpretation of the above would likely lead to:

	ARCH-unknown-netbsd-netbsdelf
or	ARCH-unknown-netbsd-netbsd-elf (?)

(ulgh :-).

	Andrew