Re: kern/43063: Please delete __NetBSD_Prereq__() from <sys/param.h>

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/43063; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/43063: Please delete __NetBSD_Prereq__() from
        <sys/param.h>
Date: Sat, 29 May 2010 19:57:55 +0000

 On Mon, Mar 29, 2010 at 02:35:03AM +0000, Robert Elz wrote:
  >    |  Checking what's in sys/param.h (as opposed to calling uname()) is in
  >    |  fact the best way to test the version of the userland libs you have...
  >  
  >  Perhaps, though I'd have thought /etc/release should be even better.   But
  >  unfortunately, much build stuff (like anything using autoconf for this kind
  >  of test, I believe, including pkgsrc's system version tests) doesn't go
  >  looking in sys/param.h, it does "uname -m" instead - that's exactly why
  >  libkver works for doing pkg_comp builds (or why it is needed, param.h
  >  should have the same info, but isn't usually used).
 
 Right.
 
  >    |  (Patching in a configure test is the *right* way, but quite a bit too
  >    |  involved.)
  >  
  >  Exactly ...   because you're getting the version from pkgsrc, you're
  >  getting uname output, which will tell you precisely nothing about whether
  >  or not the system's libc happens to be the version with terminfo in it or
  >  not...   I could boot such a kernel (briefly) and try building emacs
  >  (outside of pkg_comp) just to demonstrate it if needed...
 
 Yeah, but in this case it was a tradeoff between what's right and
 what's feasible to wedge into an old version of emacs.
 
 I am sufficiently annoyed with emacs23 that I'm contemplating doing
 some heavier maintenance on emacs20, in which case fixing this up
 properly might be feasible. But that's neither here nor there.
 
 Anyhow, I like Martin's suggestion.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost