用最新版linux源码包编译内核时是否也要重新安装下Linux API Headers?

在LFS中，总是能见到这么一个过程
6.7. Linux-2.6.27.4 API Headers

make mrproper
make headers_check
make INSTALL_HDR_PATH=dest headers_install
cp -rv dest/include/* /usr/include

但是在一般的发行版如debian中编译内核时，并没有见着类似的安装Linux API Headers 的命令，难道在编译内核时不需要同步更新下Linux API Headers？
在编译其他软件时，有些要用到Linux API Headers，不同步更新不会有问题么？

作者: lofeng 发布时间: 2009-06-05

我也想知道答案，我编译内核，从2.6.16升级到2.6.28的时候，好像不同步头文件更新也能编译通过。

作者: 独孤不羁发布时间: 2009-06-07

问题不大，只要内核版本大于头文件的安装版本一般问题不大。

作者: youbest 发布时间: 2009-06-07

我从来就不理头文件，一直到现在也好像没出现过问题。

作者: 老李飞刀发布时间: 2009-06-08

简短的回答是，不用，且不能。
复杂一点的回答是，不需要，不过可以更新，更新内核头文件有必要更新整个工具链；要保证安全更新工具链，最简单的方法是重做系统。

等您建立起清晰的 "工具链、编译时、运行时" 概念时，您会明白怎么做，及为什么要那么做。

作者: 聚焦深空发布时间: 2009-06-08

在编译内核时make headers_install
跟
apt-get install linux-libc-dev
效果是否一样？

作者: lofeng 发布时间: 2009-06-09

glibc是GNU C Library，是否也就是通常所说的C运行时库？
在编译这个库时，要用到内核中相关的函数，所以就必须内核头文件，也即Linux API Headers
又因为Linux系统是建立在C语言之上的，所以C运行时库即glibc非常重要而不可随意升级，因此所用的Linux API Headers也不可随意替换？

基于上面所说，系统的Linux API Headers必须跟编译系统的glibc时所用的Linux API Headers版本一致，是否是这样？还请大侠指正

作者: lofeng 发布时间: 2009-06-09

引自 http://www.linuxfromscratch.org/lfs/...08/kernel.html

LFS 手册有这麽一段：

引用:

Warning

The headers in the system's include directory should always be the ones against which Glibc was compiled, that is, the sanitised headers from this Linux kernel tarball. Therefore, they should never be replaced by either the raw kernel headers or any other kernel sanitized headers.

即是说，你的 headers 应该跟编译 glibc 时所使用的要一致，因为这样才确保 glibc 能提供的跟你编译软件时被定义的才一致

不一致未必出问题，不出问题的原因是应用的函数未必被采用

所以要替换系统的 headers，首先应该重新编译安装 glibc，也就是重建 toolchain，不过编译安装 glibc 是极高危动作，请慎之！

作者: d00m3d 发布时间: 2009-06-13

引用:

作者: lofeng

在编译内核时make headers_install
跟
apt-get install linux-libc-dev
效果是否一样？

Short answer：不一样

作者: d00m3d 发布时间: 2009-06-13

引用:

在编译内核时make headers_install
跟
apt-get install linux-libc-dev

这个有点明白，linux-libc-dev貌似是debian提供的经过其净化的头文件包，而make headers_install安装的是内核中的头文件。
在debian中推荐用linux-libc-dev，但是在安装编译某些软件时，譬如vmware tool时，还是要求linux headers，不知是何故。
而debian中貌似是推荐用linux-libc-dev的，所以我只好先装上Linux headers，以装vmware tool，然后remove linux headers，最后再装上linux-libc-dev，这样不知可妥当？

作者: lofeng 发布时间: 2009-06-13

引用:

作者: d00m3d

引自 http://www.linuxfromscratch.org/lfs/...08/kernel.html

LFS 手册有这麽一段：

即是说，你的 headers 应该跟编译 glibc 时所使用的要一致，因为这样才确保 glibc 能提供的跟你编译软件时被定义的才一致

不一致未必出问题，不出问题的原因是应用的函数未必被采用

所以要替换系统的 headers，首先应该重新编译安装 glibc，也就是重建 toolchain，不过编译安装 glibc 是极高危动作，请慎之！

引用:

glibc是GNU C Library，是否也就是通常所说的C运行时库？
在编译这个库时，要用到内核中相关的函数，所以就必须内核头文件，也即Linux API Headers
又因为Linux系统是建立在C语言之上的，所以C运行时库即glibc非常重要而不可随意升级，因此所用的Linux API Headers也不可随意替换？

基于上面所说，系统的Linux API Headers必须跟编译系统的glibc时所用的Linux API Headers版本一致，是否是这样？还请大侠指正

多谢毁灭兄
对于kernel header以及glibc的重要性已有理解
但是是否正如我上面所说的呢？

作者: lofeng 发布时间: 2009-06-13

引用:

作者: lofeng

这个有点明白，linux-libc-dev貌似是debian提供的经过其净化的头文件包，而make headers_install安装的是内核中的头文件。
在debian中推荐用linux-libc-dev，但是在安装编译某些软件时，譬如vmware tool时，还是要求linux headers，不知是何故。
而debian中貌似是推荐用linux-libc-dev的，所以我只好先装上Linux headers，以装vmware tool，然后remove linux headers，最后再装上linux-libc-dev，这样不知可妥当？

空口无凭，请给出引用出处。

您需要分清楚用户空间和内核空间。
用户空间进程是不允许直接操作内核空间资源的。
安装 vmware 内核模块，需要运行中内核对应内核头文件，一般位于 /lib/modules/`uname -r`/source/ 下，对应内核空间。
工具链使用的内核头文件位于 /usr/include，对应用户空间。

作者: 聚焦深空发布时间: 2009-06-13

引用:

作者: lofeng

多谢毁灭兄
对于kernel header以及glibc的重要性已有理解
但是是否正如我上面所说的呢？

大致是這樣的

作者: d00m3d 发布时间: 2009-06-13

深空兄，请看下面的输出，是否能表明“debian中貌似是推荐用linux-libc-dev的？”

引用:

debian:~# apt-cache show linux-libc-dev
Package: linux-libc-dev
Priority: optional
Section: devel
Installed-Size: 3864
Maintainer: Debian Kernel Team <[email protected]>
Architecture: i386
Source: linux-2.6
Version: 2.6.26-15lenny3
Replaces: linux-kernel-headers
Provides: linux-kernel-headers
Conflicts: linux-kernel-headers
Filename: pool/updates/main/l/linux-2.6/linux-libc-dev_2.6.26-15lenny3_i386.deb
Size: 746696
MD5sum: a7f6e45793b33ae4e05b831785fd9f42
SHA1: d1a46af068db95b6d9a238868f14bb6792751b9b
SHA256: fb036100908240b7e165731ccf5890ef5c6f8ba2fb15bdf7aca352e5799d65be
Description: Linux support headers for userspace development
This package provides userspaces headers from the Linux kernel. These
headers are used by the installed headers for GNU glibc and other system
libraries.
Tag: devel::lang:c, devel::library, implemented-in::c, role::devel-lib

作者: lofeng 发布时间: 2009-06-16

以前，安装 debian 时，基本系统默认安装的是实实在在的 linux-kernel-headers。
查了一下自己的 lenny 环境，确实没注意到，不知什么时候改成 linux-libc-dev，并作为 linux-kernel-headers 虚拟包存在。

这不说明 debian "推荐"，只是默认安装罢了，不需要工具链的情况可以安全删除。

作者: 聚焦深空发布时间: 2009-06-17

给一个反例：详情记不清楚了，有一次在升级内核时，觉得LFS编译系统时的初始内核与正在升级的新内核版本差太多了，于是自作主张把内核头文件用新内核替换了，结果以后再编译其它软件时就出了一堆的错误。

作者: linux001 发布时间: 2009-06-17

引用:

作者: 聚焦深空

空口无凭，请给出引用出处。

您需要分清楚用户空间和内核空间。
用户空间进程是不允许直接操作内核空间资源的。
安装 vmware 内核模块，需要运行中内核对应内核头文件，一般位于 /lib/modules/`uname -r`/source/ 下，对应内核空间。
工具链使用的内核头文件位于 /usr/include，对应用户空间。

我安装的debian 5.0.1中并没有深空兄所说的/lib/modules/`uname -r`/source/目录，如下所示。
小弟愚笨，深空兄所说的“安装 vmware 内核模块，需要运行中内核对应内核头文件，一般位于 /lib/modules/`uname -r`/source/ 下，对应内核空间。”不是很明白，还请指教。多谢~~

代码:

 
debian:~# cd /lib/modules/`uname -r`
debian:/lib/modules/2.6.26-2-686# ls -l
总计 1872
drwxr-xr-x 9 root root 4096 06-08 16:58 kernel
-rw-r--r-- 1 root root 410493 06-08 17:45 modules.alias
-rw-r--r-- 1 root root 69 06-08 17:45 modules.ccwmap
-rw-r--r-- 1 root root 392265 06-08 17:45 modules.dep
-rw-r--r-- 1 root root 813 06-08 17:45 modules.ieee1394map
-rw-r--r-- 1 root root 451 06-08 17:45 modules.inputmap
-rw-r--r-- 1 root root 22763 06-08 17:45 modules.isapnpmap
-rw-r--r-- 1 root root 74 06-08 17:45 modules.ofmap
-rw-r--r-- 1 root root 297851 06-08 17:45 modules.pcimap
-rw-r--r-- 1 root root 1429 06-08 17:45 modules.seriomap
-rw-r--r-- 1 root root 180744 06-08 17:45 modules.symbols
-rw-r--r-- 1 root root 554230 06-08 17:45 modules.usbmap
debian:/lib/modules/2.6.26-2-686# cd kernel/
debian:/lib/modules/2.6.26-2-686/kernel# ls -l
总计 28
drwxr-xr-x 3 root root 4096 06-08 16:58 arch
drwxr-xr-x 3 root root 4096 06-08 17:45 crypto
drwxr-xr-x 54 root root 4096 06-08 16:58 drivers
drwxr-xr-x 51 root root 4096 06-08 17:45 fs
drwxr-xr-x 6 root root 4096 06-08 17:45 lib
drwxr-xr-x 37 root root 4096 06-08 16:58 net
drwxr-xr-x 11 root root 4096 06-08 17:45 sound

作者: lofeng 发布时间: 2009-06-18

引用:

作者: 聚焦深空

以前，安装 debian 时，基本系统默认安装的是实实在在的 linux-kernel-headers。
查了一下自己的 lenny 环境，确实没注意到，不知什么时候改成 linux-libc-dev，并作为 linux-kernel-headers 虚拟包存在。

这不说明 debian "推荐"，只是默认安装罢了，不需要工具链的情况可以安全删除。

在安装vmware tool时系统已经有了linux-libc-dev，还是提示需要kernel headers，很是郁闷

作者: lofeng 发布时间: 2009-06-18

看了深空兄在http://www.linuxsir.org/bbs/thread349110.html中的帖子：

引用:

内核头文件是编译工具链一部分，要换，整个都要重编译。
编译不同版本内核的模块使用该内核自带头文件就是，但不能直接用其头文件覆盖系统中的内核头文件，否则出问题没法查清的。
如果真的依赖另一个版本的内核头文件，偶的安装方式会出问题的，事实是没有问题。

对 KMS 的工作方式，不是太清楚，但一般情况下，内核里的东西对用户空间程序应该是透明的，内核空间用户空间交流要通过设备文件（内核设备驱动）、系统调用（libc作中介）。
需要读源代码或找 KMS 文档资料。

想运行 3D 游戏，出现问题，无法改变分辨率、刷新率，整个被内核接管了，不知少配置什么东西或少装什么用户空间工具。

对glibc的作用理解加深了一些：一般情况下，内核里的东西对用户空间程序应该是透明的，内核空间用户空间交流要通过设备文件（内核设备驱动）、系统调用（libc作中介）。

以下引用出自http://www.gnu.org/software/libc/#Resources

引用:

Any Unix-like operating system needs a C library: the library which defines the ``system calls'' and other basic facilities such as open, malloc, printf, exit...
The GNU C library is used as the C library in the GNU system and most systems with the Linux kernel.

defines the ``system calls'' 是在glibc中定义的么？

引用:

系统调用是内核提供给应用程序的接口，应用对底层硬件的操作大部分都是通过调用系统调用来完成的。

glibc不是只是使用系统中的函数的么来实现系统调用的么？这样的话怎么能称之为定义呢？

作者: lofeng 发布时间: 2009-06-18

楼主，不客气的说，您现在基础太差，大家解释越多您越困惑。
对您来说，现在最好的方法是找 *nix-like 方面的资料充充电。
喜欢书本，可以到图书馆借，不要用买的，打好基础后十有八九会后悔买书，至少目前大部分中文图书是这样。
喜欢快餐式的，可以快速的把本站精华贴中您感兴趣的部分过一遍。

debian相关的问题是您不够仔细，您用debian方式安装内核时显然没有仔细阅读提示。

作者: 聚焦深空发布时间: 2009-06-19

深空兄我知道自己的基础比较差也在慢慢看书但是有些问题看书一下子是找不着答案的
因此还请您帮忙解决上面的几个问题

另外，正如您所说现在的中文类书籍值得购买的太少了，还请推荐几本比较好点的书籍

先行谢过了

作者: lofeng 发布时间: 2009-06-19

不要找借口，如果您说的是事实，且人人如此，那最初那个人是怎么获得自己需要的信息的？

偶不知您的侧重点，书只能随便推荐一下，入门读物：各个发行版的用户手册、freebsd 用户手册（可以交叉引证，并扩展视野）、unix痛恨者手册、linux 相关的 howto（大部分有中文版），再深入可以根据自己的兴趣找（这没什么可指导的，到这个阶段您应该自立了）。
或者，您可以把各个发行版的 wiki 作为自己的入门读物。
对编程感兴趣的话，手边至少要有您所用语言的用户手册。

最重要的，多动手验证，少找借口。

您前面无法编译 vmware 模块原因很简单，模块是内核空间的东西，需要的是内核空间使用的内核头文件，而不是给工具链使用的净化过的头文件。

作者: 聚焦深空发布时间: 2009-06-19

引用:

作者: 聚焦深空

不要找借口，如果您说的是事实，且人人如此，那最初那个人是怎么获得自己需要的信息的？

偶不知您的侧重点，书只能随便推荐一下，入门读物：各个发行版的用户手册、freebsd 用户手册（可以交叉引证，并扩展视野）、unix痛恨者手册、linux 相关的 howto（大部分有中文版），再深入可以根据自己的兴趣找（这没什么可指导的，到这个阶段您应该自立了）。
或者，您可以把各个发行版的 wiki 作为自己的入门读物。
对编程感兴趣的话，手边至少要有您所用语言的用户手册。

最重要的，多动手验证，少找借口。

您前面无法编译 vmware 模块原因很简单，模块是内核空间的东西，需要的是内核空间使用的内核头文件，而不是给工具链使用的净化过的头文件。

深空兄教训的是

我是电子信息专业出身，现在做的工作都是基于单片机等一些应用，平常的工作是设计硬件，然后写代码，但是都是比较简单的那种。而且感觉这个行业门槛太低，要求不高，所以很有危机感，所以想往嵌入式方向发展，所以也有了现在的这些尝试和问题

其实我并没有纠缠于为什么无法编译vmware tool，我也知道是头文件不对，我想知道的是各个头文件的作用。正如您最后所说的，有的内核头文件是给内核空间的相关程序和模块使用的，而工具链是属于用户空间的，所以不使用内核头文件。而且，工具链中的glibc提供了一种途径，使得用户空间的程序可以调用内核中的特定函数，当然，glibc中也提供了很多头文件，这些头文件，就是供用户空间的程序来使用。
不知我现在的理解可对，还请深空兄指正。
（其实对于红色部分标出的部分我不是很肯定其正确性，根据您说的，“给工具链使用的净化过的头文件”，这里说的是否是内核头文件，只不过是经过净化了。这样的话，我又有困惑了。一个系统里面可以有两个不同的内核头文件么“1.内核空间使用的内核头文件 2.给工具链使用的净化过的头文件”？）

作者: lofeng 发布时间: 2009-06-19

很佩報樓主這種屢敗屢戰的求知慾，有這種求知的精神對你日後處事會有幫助

可是求知歸求知，提問是要有智慧的，特別是向高人求教的時候。沒有章法，未經思考、分析、搜索或充份證據時就發問（或發言），別人就有機會認為你無知，如果別人早已給你明示卻又不跟從，那麼別人又會對你有何看法？

我在這主題裡有些鏈結，閱後應該對你搜索資料時有用武之地

http://www.linuxsir.org/bbs/thread294352.html

英語的，但別找借口說自己英語不行，否則日後你只會一事無成！

作者: d00m3d 发布时间: 2009-06-20

多谢毁灭兄
今天被认为无知我不在乎我在乎的是明天自己有没有不被认为无知的能力
我只所以一直继续着是因为没有完全理解深空兄说的那些
我会按照深空兄指点的继续学习的多谢~~
正在看google 101/201/301

作者: lofeng 发布时间: 2009-06-23