On Thu, 24 Apr 2003, John Darrow wrote:

> Unfortunately, I cannot do the compiling on the -current-kernel
> machines, despite the fact that they're the fastest ones available.
> Why?  Because the self-identification of the machine as -current will
> cause certain feature tests, etc. to fire when they shouldn't.
>
> Though the kernel may be capable of certain newer syscalls, etc., the
> lack of either header files or library wrappers for them _should_ mean
> that, as far as applications are concerned, the syscalls are not
> present.  Unfortunately, if they check uname to determine if they're
> running on an "OS version" with said feature (as e.g. X does), they
> get what is ostensibly the wrong answer for their situation.

What's just as bad, is when the configure script checks libraries and
headers for every feature in detail, but then incorrectly "brands" the
binaries with the result of "uname" (which comes from the kernel
version). All NetBSD pkgsrc packages are also branded (occasionally
incorrectly) with the result of "uname".

> Thus, I would prefer that uname, sysctl, etc. return a version number
> corresponding to the "userland" version, probably as compiled into
> libc, unless _explicitly_ asked for the kernel version (which can
> also usually be determined from dmesg, 'what /netbsd', etc.).
> Given that uname(3) and sysctl(3) are both userland functions, and not
> actually part of the kernel like syscalls are, it only makes sense for
> their results to also be tied to the userland version...

I'm starting to think so, too -- about uname(3). If you parse
kern.version, however, you should get just what you asked for.

Frederick