[lfs-support] Headers in the system's include directory. Still Confused.

Ken Moffat zarniwhoop at ntlworld.com
Fri Feb 24 17:08:19 PST 2012


On Fri, Feb 24, 2012 at 06:27:24PM -0600, alupu at verizon.net wrote:
> 
> At the very least, your answers have helped me sharpen
> my big question which, after all, is based on this actual,
> immovable fact:
> 
> 'udev-181' expects to find in '/usr/include/linux' a file,
> 'input.h', which contains the definition of a so called
> BTN_TRIGGER_HAPPY.  Good, OK.  I understand.
> 
> Another secondary fact (which is most likely on me),
> my current '/usr/include/linux/input.h' does NOT contain it.
> Maybe because file too old, a mistake/omission in 6.7, etc., etc.
> Bad, Not-OK.
> 
 Udev has a reputation for being unpleasant and not
backward-compatible.  In the (distant) past I upgraded some old
systems because of a udev vulnerability, but it's not something I
would expect to work as a matter of course for any random version of
udev.  In fact, for some I had to stick with an old verison and use
patches from debian.

 The LFS book is concerned with building a new system.  Compare udev
in BLFS where we say: Unlike any other package in the BLFS book,
there is no set version of Udev specified to download. Several
version updates to LFS and none to BLFS means there are probably
many different versions of Udev on the platforms that BLFS is being
built upon. Therefore, you should download and use the version of
Udev your computer currently uses.

 What we don't add is that the build instructions for each version
of udev change, so you *really* need to keep the version of the LFS
book which you used (or your LFS udev script, if you have one)
around to be able to rebuild udev if you need to  - I had that
recently when testing gnome-3, several packages need a fuller udev
and I had to go back to my original LFS script to sort it out - that
was one place where running the testsuite stopped me installing a
b0rken version (said the man who normally trusts testsuites only as
far as he can throw them).
> ------
> 
> Now I can crystallize my "header" question a lot more.
> 
> We know an 'udev-xxx' (say, 'udev-173') did not need
> BTN_TRIGGER_HAPPY, while a later udev (say, 'udev-181')
> aware of a _newer_ 'input.h' file floating around,
> which does contain BTN_TRIGGER_HAPPY, expected the user
> (i.e., me) to have this file in '/usr/include/...'.
> 
> Based on that, here's (finally) the finalized question:
> 
> IF I'm up to date with the LFS book, and am at
> the latest Glibc, v2.14.1 (issued 07-Oct-2011, FWIW)
> no matter what kernel version was at the time (say, 3.0.9)
> - assuming I compiled Glibc-2.14.1 in Nov. 2011 -
>  the "sanitized" headers installed as per Book 6.7
> provide a guaranty for me that they contain the "correct" 'input.h'
>  for as long as I stay with Glibc-2.14.1, no matter what
> the udev version du jour (181++) might be.
> 
> Or put another way around, udev-173++ developers rely on
> and expect me to have the Nov. 2011 headers (sanitised:)
> and as for me, I'll be fine for any future udev release,
> as long as the Glibc stays at 2.14.1.
> 
> Is that so?

 You seem to think that we support upgrading an existing system
in-place.  For trivial packages in BLFS, and indeed for many
packages in LFS, that usually works.  For others, such as glibc, we
do not advise it - sometimes works, other times trashes the system.

> 
> BTW, I didn't know that developers (udev and otherwise) are
> continuously careful to stay within the latest Glibc-thenKernel confines.
> 
> -- Alex
> 
> PS - I don't have any idea when BTN_TRIGGER_HAPPY made its
> way into 'input.h'.  Too bad.  It'd've been interesting.

 Google suggests 2.6.34-rc1, and found a report that udev-172 did
not compile because it needed BTN_TRIGGER_HAPPY.  Curiouser and
curiouser.  Sorry this wasn't the reply you wanted.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list