* Harlan Stenn <[EMAIL PROTECTED]> [2002-01-26T16:21-0500]:
> >>>>> "Peterll" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> Peterll> You don't. The config.guess command reports information about the
> Peterll> hardware and the kernel
>
> config.guess returns CPU-Vendor-OS, not CPU-VENDOR-Kernel.
>
> This is a bikeshed issue.
>
> Things went wonky when the Linux folks decided that a 4-part string was
> somehow allegedly useful, and another bikeshed ensued.
Arguably, in the case of Linux, where sometimes
<cpu>-unknown-linux-gnu was used, you can see it as 3 part (and also
have a regex for it):
1) CPU: <cpu>
2) vendor: unknown
3) OS: linux-gnu
So, if someone decides to reuse the Linux kernel, but make a whole new
userland, they can: linux-foo. Of course, the use of '-' in the last
part is be a bit confusing (linux_gnu would've been an
alternative), but well... that train is gone, I think. :)
But more important, things are not really standardized anyway: there
are opinions on dropping the vendor part entirely, or replacing the
unknown part with 'pc' for x86 (or on the Linux side, by the
distribution, e.g. i386-redhat-linux, which would change the vendor
semantics from 'hardware vendor' to 'software vendor'.
The current situation for me is like this:
Taken some randomly chosen config.guess from my system, I get:
(real)~$ /usr/pkgsrc/shells/zsh/work/zsh-4.0.4/config.guess
alpha-unknown-netbsd1.5.2
(real)~$ /usr/pkg/share/libtool/config.guess
alpha-netbsd1.5.2
(real)~$ /usr/pkgsrc/net/ntp4/work/ntp-4.1.0/config.guess
alpha-unknown-netbsd1.5.2
(real)~$
As you can see, different output by different config.guess scripts.
Also notable, the config string doesn't tell you I'm running an ELF
system (for i386 it is i386-netbsdelf1.5 or even i386-netbsdelf1.5.3,
apparently), but it really is ELF:
(real)~$ file $(which file)
/usr/bin/file: ELF 64-bit LSB executable, Alpha (unofficial), version 1,
dynamically linked (uses shared libs), stripped
This is a comment in one of the config.guess scripts:
# The Operating System including object format, if it has switched
# to ELF recently, or will in the future.
conclusion: Big Mess(tm). =)
To make a long story short, it might be wise to make config.guess
smart enough to distinguish between NetBSD and Debian/NetBSD[1], since
they are quite different and it can prove helpful to make this piece
of information accessible.
AIUI, the GNU userland will be used as much as possible, so
<cpu>-unknown-netbsd-gnu
would come to mind, or
<cpu>-unknown-netbsd-debian
(is there another sane choice, I've overlooked?)
Obviously, I'd favour to drop the "elf" bit entirely, since an a.out
version will very likely not happen, so we don't have to mention ELF
explicitly. Also, I don't see the point in encoding the version number
here either (can somebody shed some more light on this?), since we
just keep the kernel, but not the userland.
[Besides it's not even clear to me, which meaning the NetBSD version
number will have to Debian/NetBSD. Will it just be the kernel
version? As release version it wouldn't make much sense here as
well, since it is unlikely that we can/want to keep completely in
sync with NetBSD with that.]
I haven't fully thought out, what would be the most reasonable and
future-compatible choice here. Suppose some other software vendor
wants to use the NetBSD kernel and the GNU userland, but makes
different design decisions wrt. use of libc, for example. Using glibc
instead would make that system more of a netbsd-gnu system, I'd think.
Once we've decided, which config string to use, we should find a way
how to detect it properly (and distinguish it from original NetBSD),
which was Jimmy's original point ;)). This seems not as easy as one
would think...
[The Debian/BSD people might want to read up a bit on that in the
autoconf ML archives: http://mail.gnu.org/pipermail/autoconf.mbox/autoconf.mbox
for example <[EMAIL PROTECTED]>]
> You can probably tell what side of the fence I live on...
Well, I definitely don't want to start a flamewar here, I merely want to
find a workable solution that won't bite us in the future.
Cheers,
Michael
[1] or whatever it will be called
--
() ASCII ribbon campaign | irc.openprojects.net | GPG: F65C68CD
/\ against HTML mail | #debian-bsd | PGP: 1D0DD0B9
