config.{sub,guess} and NetBSD
Okay. So. The autotools-dev package has scripts for config.{sub,guess} that
are supposed to be used by any package that has them. Fine, well, and good.
Currently they identify an Intel NetBSD host as one of the following,
depending on OS version:
* 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)
This makes things in dpkg's archtable ugly, in one direction - and nigh
impossible, in the other (since it does a lookup of GNU -> archtable, then
does a reverse of archtable -> GNU which can only have one value, and
throws errors - rightly - if what it's table has doesn't match what the
system tells it).
Things like GCC make use of dpkg-architecture -qDEB_BUILD_GNU_TYPE, which
*must* match what it is building (*not* what the system currently is) -
I'm not sure if this is a bug or not, but it's damned inconvenient, as GCC
puts things in one directory, and dpkg tells it another - and on any of the
linux platforms, different kernel versions and a.out/elf map to the same
GNU OS section.
So. Questions.
1) Is the behavior of GCC buggy?
2) Do we intend to have any non-ELF NetBSD platform port any time in the
forseeable future?
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)
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).
Thoughts?
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Reply to: