Re: /usr/include/linux and stuff

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Al" == Al Hudson <eah106 [at] york.ac.uk> writes:

    Al> On Tue, 15 Feb 2000 will [at] south-of-heaven.demon.co.uk wrote:

    >> What exactly is in here? On RedHat the glibc package installs
    >> it. This seems pretty damn wrong (the contents depend on the
    >> kernel revision in use at the time). Should I just symlink to
    >> /usr/src/linux/include/linux?

    Al> No, don't do that. To be honest, it (/usr/include/linux)
    Al> shouldn't be there full stop, although the glibc guys insist
    Al> on installing it every time, most annoying. It's rank
    Al> naughtiness.

It's not glibc itself that does this AFAIK---when building glibc you
use a symlink, at least that's the way it used to be---it's the package
maintainer.  If your distro is Red Hat they're closely related,
although the top glibc maintainer has made it plain that having his
employer (Cygnus) merged with Red Hat did not fill him with joy.

As for "rank naughtiness", do you have an alternative suggestion that
doesn't involve either (1) moving glibc into the kernel (in the sense
of requiring a glibc rebuild with every kernel rebuild) or (2)
undebuggable crashes due to glibc and /usr/src/linux/include/linux
having different ideas about the way macros are expected to expand?
<drepper [at] cygnus.com> wants to talk to _you_!

    Al> What's in there? Full kernel headers. Screws package
    Al> management. What? You have different kernel sources to that
    Al> which you're running? Tough.

glibc (any libc for that matter) will also make heavy use of kernel
includes.  So it's quite possible that glibc, the running kernel, and
the /usr/src/linux/include/linux tree have three different ideas about
what's in the include files.  The kernel calls themselves are pretty
robust, but a lot of those macros and typedefs are not, and glibc
tends to use them in ways intended to hide changes in
/usr/src/linux/include/linux.

If your program uses both glibc and direct calls to the kernel, you
probably want to compile with the same set of headers as your glibc,
and hope the kernel can take care of itself.

    Al> Go into any include tree and do a 'cat *.h | grep
    Al> __KERNEL__'. All that crap is there because of libc5, and
    Al> glibc doesn't seem to have changed its errant ways...


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.