re: config.{sub,guess} and NetBSD

[matthew green <mrg@eterna.com.au>]

     * i386-unknown-netbsdelf1.5  (1.5 major release, any minor)
     * i386-unknown-netbsdelf1.6. (1.6_{BETA,RC}*)
     * i386-unknown-netbsdelf1.6  (if you force the kernel to lie)

hmm, the "standard" config.guess scripts should end up with
i386-unknown-netbsdelf<release>.  ie

	i386-unknown-netbsdelf1.5.3 for NetBSD 1.5.3
	i386-unknown-netbsdelf1.6_rc3 for 1.6_RC3
	i386-unknown-netbsdelf1.6F for -current.
   
   1) Is the behavior of GCC buggy?

quite often. :-)  (don't know about right now.)
   
   2) Do we intend to have any non-ELF NetBSD platform port any time in the
      forseeable future?

probably not; there is only one remaining non-ELF port in netbsd and
the plan is for it to be switched as soon as someone invents ELF for
that cpu architecture (ns32k).
   
   3) Can we come up with a workaround for #2, if true?
   
   4) Is it feasible to just change the config scripts and require the new
      when trying to build on NetBSD systems? (presumably having them return
      'i386-netbsd', much like they do for various Linuxes)

currently, only linux output for config.guess does not include the
OS release... everything else does.  i don't think changing it would
be accepted.
   
   Note that in the case of non-i386 ports, where 'unknown' may actually be a
   valid vendor, config.guess is *only* filling it out if there is a single
   vendor value - IE, something that can be put into the archtable as-is, and
   come back out again without conflict. So it could be i386-unknown-netbsd as
   far as it really matters; it's the 'elf' and version bits that cause issues
   (or rather, the version bit *does* cause issues, the elf bit *could* cause
   them, in theory).

note that lots of packages (such as GCC, binutils, etc.) *depend* on
seeing $target == i386-*netbsdelf* to enable ELF support over a.out.


.mrg.