SLUG Mailing List Archives
Re: [SLUG] Debian & .h files / Kernel building
- To: Graeme Merrall <graeme@xxxxxxxxxxxxx>
- Subject: Re: [SLUG] Debian & .h files / Kernel building
- From: Anand Kumria <wildfire@xxxxxxxxxxxxxxxxxx>
- Date: Mon Aug 14 15:24:04 2000
- Cc: slug@xxxxxxxxxxx
- Reply-to: slug@xxxxxxxxxxx
- User-agent: Mutt/1.2i
On Mon, Aug 14, 2000 at 11:18:33AM +1000, Graeme Merrall wrote:
> On Mon, Aug 14, 2000 at 11:01:07AM +0200, Craige McWhirter wrote:
> > I'm trying to work out what Debian package I need to install to
> > supply me with files such as sys/types.h, fcntl.h etc, related
> > to making a kernel. These files usually live in /usr/include.
> > I've got them on one Debian system but not another. One was a
> > clean Potato install, the other an upgrade from Slink to Potato.
> > I've not been able to figure out which package supplies me with
> > those files. If anyone can shed some light on that for me, or even
> > better let me know how I can use dpkg tools to find out which package
> > provided a particular file, that'd be great.
> other Debian-ites may be able to help with this but I found this setup quite
> confusing. There's /usr/include/linux, kernel-headers and include/linux in
> the linux kernel source. I had a read about kernel-headers in the docs that
> came with it but it didn't make much sense. I had a problem compiling the
> NVidia kernel module and the solution I found was to backup
> /usr/inlude/linux and link it to /usr/src/linux/include/linux so it would
If you tell LInus this, he will hate you forever.
As far as he is concerned *any* distribution which make kernel source
available under /usr/src/linux is broken (read the release note for 2.4).
I'm not familiar with previous versions of Debian but 2.2 (out in a day
or so I hope) puts them in /usr/src/kernel-source-<version>
/usr/include/linux should always be provided by your C Library as changes
to structures, or more usually, differences in structures as common.
Seperating out the includes for the C library and the kernel source means
that each can change without affecting the other. Thus stopping the
(I hope) problem that different C libraries break with different kernels.
Different C Libraries may still break applications -- but likely that
application was doing something bad in the first place.