> > Nothing but libc6-dev is supposed to set symlinks in > > /usr/include; certainly the kernel packages should not. > > > > YES they SHOULD! If the /usr/include symlinks are pointed to > /usr/src/kernel-headers-2.0.29 and you install kernel-source-2.0.32 you > MUST change those symlinks to point to /usr/src/linux-2.0.32/include/...
Take a look at /usr/doc/kernel-source-2.0.33/README.headers.gz It explains the new (currently Debian-specific) policy for kernel include files. Some excerpts: > Kernel Headers and libc6-dev package > ==================================== > > [...] > > Traditional two symlink approach > =========== === ======= ======== > > Under libc5, it was standard for part of the user interface to > libc to be exported from the kernel includes, via /usr/include/linux > and /usr/include/asm. Traditionally, this was done by linking those > two directories to the appropriate directories in > /usr/src/linux/include. This is the method documented in the install > instructions for the kernel sources, even today. > > Why that is bad > === ==== == === > > [...] > > Debian's libc6 method > ======== ===== ====== > [...] The variation is that we link to header files from > a specific kernel version, namely 2.0.32, which are the headers that > libc was compiled with. Whereas we used to link to any old kernel in > the original libc5 symlink, the new libc6 symlink is to > /usr/src/linux-2.0.32, which is a symbolic link that holds headers > from a *static, well known*, *supported*, tested kernel version, and > we let the kernel-headers package handle architecture dependencies > (which it had to anyway). > > [...] > > This is a working technical solution to having libc > development package contain/depend on a well known static set of > kernel headers (insulating the vast majority of programs that are not > closely tied to kernel version specific internal data structures), > while allowing the kernel headers to vary from architecture to > architecture, and still allowing device driver authors from having > any set of kernel headers they want on the machine through the simple > artifice of adding a -I flag to the compilation flags. > So I believe the Makefile for kernel-source-2.0.33 will include the correct kernel headers using the -I option. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
