Re: config.{sub,guess} and NetBSD
On Thu, Sep 05, 2002 at 01:31:24PM +1000, matthew green wrote:
>
> * 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.
I can only go by what the majority of the config.guess scripts appear to
show - which is a '.' for anything with _ or - in it's release name per
uname -r, and the major portion for other stuff.
> 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).
Hmmm. That opens up some options, then.
> 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.
Yes, and currently, Debian Is Linux (tm). The question then becomes whether
we mangle config.guess, or mangle dpkg-architecture to *fundamentally*
change what it currently does. Part of why I wanted to discuss it.
> 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.
We could possibly make it i386-unknown-netbsdelf (and skip the version
info), given the answer to #2. Perhaps we should ask the dpkg folks, first,
though. I'll try to get an opinion from one...
*****
Addendum from IRC:
<doogie__> Fentonator: I'll fix that better for 1.11
<doogie__> don't know how yet, but I'll do something.
So, the dpkg folks are aware of it, and intend to find some way to fix it
(and, from what I've heard, the entire concept may be different in 1.11
anyway...)
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Reply to: