3,881
社区成员
发帖
与我相关
我的任务
分享原创——编译全部版本的Linux内核并可用——x86_64架构，2.4.26-2.4.37
接上篇http://topic.csdn.net/u/20111205/20/1e530602-46dc-423c-b725-5eaeeb865d00.html
上篇内核降级到2.6.7,2.6.4-2.6.6经过修改也已经搞定，上篇贴子回复里已有说明
2.6.3以下会提示CPU不兼容，vmware官方解释是没打开Intel VT，但是我是打开的，而且我主机也是64位，那只能解释为内核本身的问题
这篇是以2.6内核为基础构建LFS，再降级到2.4内核，难度相对要大一些，如果不了解内核特性的变化，2.6版本内的降级误打误撞也许能成功，2.6降级到2.4必然失败。
首先说明一下2.4和2.6对LFS有影响的变化，主要有如下两点
2.4不使用ntpl线程模型，使用linuxthread
2.4不使用udev，使用devfs
那么，根据如上的两点，做兼容2.4内核的LFS就得要求
1.glibc版本不得超过2.3.6，并且要使用linuxthread线程模型
2.2.4下不可启用udev
3.modules tools要么装双版本，要么只用2.4的版本
原先计划2.4分两个版本的LFS，现在发现一个版本就可以搞定了
LFS 6.1.1 （2.4.26-2.4.37.11，外加2.6.16.62）
原始软件包版本：Linux 2.6.11，gcc 3.4.3，binutils-2.15.94.0.2.2，glibc 2.3.4，udev-056，etx3文件系统
我使用的版本：Linux 2.6.16，gcc 3.4.6，binutils 2.15a，glibc 2.3.6，udev-058，ext3文件系统
/opt额外安装的软件：modules 2.4.27，gcc 3.3.6
有小幅的升级，由于是64位构建，工具链的补丁基本上不用打了，参照LFS 6.5的临时系统构建就可以，中间稍微有点变化。其他软件如有编译失败，升级一个版本基本可以解决，要注意flex一定要升级到2.5.33，否则2.4版的modules tools无法编译
再次强调glibc一定要用linuxthread
而且得从LFS 5.1.1移植make_device脚本过来，用于静态创建2.4内核的/dev节点，没有udev就这点麻烦，而且明明没有的设备也在/dev里
LFS构建完成后，如果你是用的原装的2.6版的modules tools，需要额外安装modules 2.4.27，对于我这样先装新版本再装旧版本的，你需要手动将modprobe等可执行文件复制到/sbin，并且加上.old后缀
启动脚本要修改，做版本判断，2.4不启用udev。
如果你不想自己定制内核，使用发行版内核，那么2.4版本一定要注意，请使用RHEL 3或RH 9的内核配置，再将scsi等驱动编译为内建，直接用debian 3.1的内核配置会有问题（貌似debian的补丁把一些原本只能内建的特性变成了modules，而2.4版本的kconfig无法自动修复这一点）
2.4内核文档推荐gcc经典版本2.95.3编译，但是该版本没有x86_64支持，所以64为构建得使用3.2以上的，由于2.4整个生命周期都是基于2.95.3开发，所以gcc 3编译可能一些模块和特性无法使用，尤其是2.4.28以下
2.4.25以下也出现2.6.3认不出CPU的问题，暂且搁置，反正离x86_64支持的下限——2.4.20也不远了
老规矩，上gcc版本要求
2.4.37.11 3.4.6
2.4.36.9 3.4.6
2.4.35.5 3.4.6
2.4.34.6 3.4.6
2.4.33.7 3.4.6
2.4.32 3.4.6
2.4.31 3.4.6
2.4.30 3.4.6
2.4.29 3.4.6
2.4.28 3.3.6
2.4.27 3.3.6
2.4.26 3.3.6
2.4.29以上版本比2.6.0出的还晚，主要是2.4分支的bug修复和维护，相当的稳定，对gcc 3编译的支持也做得比较好
2.4.28以下处于2.4内核的主生命周期内，每个版本都有一些特性变化，编译时也会有或多或少的问题
2.4.26-2.4.28都需要把在2.4.26加入的不成熟的swiotlb特性去掉，否则许多模块都不能用。其中2.4.26还有个明显的bug，arch/x86_64/kernel/pci-gart.c中有一处使用swiotlb的代码没有加预处理，去掉swiotlb支持后编译报错，自己加上
#ifdef CONFIG_SWIOTLB
#endif
就行了
2.6.28以下内核会有几个驱动只能在gcc 2.95.3下编译，不想改代码就去掉，不是关键的驱动
从2.6.6往下的内核，做modules_install这一步的时候都要注意是否有modules存在没有连接上的符号，这些模块都是无法使用的，需要改变编译器版本、改变内核配置来解决。通常，最小化编译的内核能更大限度避免这个问题。
2.4.25-3.1全系列linux内核x86_64构建就此完成。
下一步我研究研究2.4.25以下，2.6.3以下内核认不出64位虚拟CPU的原因
有人把LFS中文翻译为“Linux完全定制手册”，除了内核外，能定制的非常多，而且，是没有经过发行版修改的原汁原味的Linux，定制LFS，Linux水平将是一次飞跃。
上篇内核降级到2.6.7,2.6.4-2.6.6经过修改也已经搞定，上篇贴子回复里已有说明
2.6.3以下会提示CPU不兼容，vmware官方解释是没打开Intel VT，但是我是打开的，而且我主机也是64位，那只能解释为内核本身的问题
这篇是以2.6内核为基础构建LFS，再降级到2.4内核，难度相对要大一些，如果不了解内核特性的变化，2.6版本内的降级误打误撞也许能成功，2.6降级到2.4必然失败。
首先说明一下2.4和2.6对LFS有影响的变化，主要有如下两点
2.4不使用ntpl线程模型，使用linuxthread
2.4不使用udev，使用devfs
那么，根据如上的两点，做兼容2.4内核的LFS就得要求
1.glibc版本不得超过2.3.6，并且要使用linuxthread线程模型
2.2.4下不可启用udev
3.modules tools要么装双版本，要么只用2.4的版本
原先计划2.4分两个版本的LFS，现在发现一个版本就可以搞定了
LFS 6.1.1 （2.4.26-2.4.37.11，外加2.6.16.62）
原始软件包版本：Linux 2.6.11，gcc 3.4.3，binutils-2.15.94.0.2.2，glibc 2.3.4，udev-056，etx3文件系统
我使用的版本：Linux 2.6.16，gcc 3.4.6，binutils 2.15a，glibc 2.3.6，udev-058，ext3文件系统
/opt额外安装的软件：modules 2.4.27，gcc 3.3.6
有小幅的升级，由于是64位构建，工具链的补丁基本上不用打了，参照LFS 6.5的临时系统构建就可以，中间稍微有点变化。其他软件如有编译失败，升级一个版本基本可以解决，要注意flex一定要升级到2.5.33，否则2.4版的modules tools无法编译
再次强调glibc一定要用linuxthread
而且得从LFS 5.1.1移植make_device脚本过来，用于静态创建2.4内核的/dev节点，没有udev就这点麻烦，而且明明没有的设备也在/dev里
LFS构建完成后，如果你是用的原装的2.6版的modules tools，需要额外安装modules 2.4.27，对于我这样先装新版本再装旧版本的，你需要手动将modprobe等可执行文件复制到/sbin，并且加上.old后缀
启动脚本要修改，做版本判断，2.4不启用udev。
如果你不想自己定制内核，使用发行版内核，那么2.4版本一定要注意，请使用RHEL 3或RH 9的内核配置，再将scsi等驱动编译为内建，直接用debian 3.1的内核配置会有问题（貌似debian的补丁把一些原本只能内建的特性变成了modules，而2.4版本的kconfig无法自动修复这一点）
2.4内核文档推荐gcc经典版本2.95.3编译，但是该版本没有x86_64支持，所以64为构建得使用3.2以上的，由于2.4整个生命周期都是基于2.95.3开发，所以gcc 3编译可能一些模块和特性无法使用，尤其是2.4.28以下
2.4.25以下也出现2.6.3认不出CPU的问题，暂且搁置，反正离x86_64支持的下限——2.4.20也不远了
老规矩，上gcc版本要求
2.4.37.11 3.4.6
2.4.36.9 3.4.6
2.4.35.5 3.4.6
2.4.34.6 3.4.6
2.4.33.7 3.4.6
2.4.32 3.4.6
2.4.31 3.4.6
2.4.30 3.4.6
2.4.29 3.4.6
2.4.28 3.3.6
2.4.27 3.3.6
2.4.26 3.3.6
2.4.29以上版本比2.6.0出的还晚，主要是2.4分支的bug修复和维护，相当的稳定，对gcc 3编译的支持也做得比较好
2.4.28以下处于2.4内核的主生命周期内，每个版本都有一些特性变化，编译时也会有或多或少的问题
2.4.26-2.4.28都需要把在2.4.26加入的不成熟的swiotlb特性去掉，否则许多模块都不能用。其中2.4.26还有个明显的bug，arch/x86_64/kernel/pci-gart.c中有一处使用swiotlb的代码没有加预处理，去掉swiotlb支持后编译报错，自己加上
#ifdef CONFIG_SWIOTLB
#endif
就行了
2.6.28以下内核会有几个驱动只能在gcc 2.95.3下编译，不想改代码就去掉，不是关键的驱动
从2.6.6往下的内核，做modules_install这一步的时候都要注意是否有modules存在没有连接上的符号，这些模块都是无法使用的，需要改变编译器版本、改变内核配置来解决。通常，最小化编译的内核能更大限度避免这个问题。
2.4.25-3.1全系列linux内核x86_64构建就此完成。
下一步我研究研究2.4.25以下，2.6.3以下内核认不出64位虚拟CPU的原因
有人把LFS中文翻译为“Linux完全定制手册”，除了内核外，能定制的非常多，而且，是没有经过发行版修改的原汁原味的Linux，定制LFS，Linux水平将是一次飞跃。
...全文
请发表友善的回复…
发表回复
lsh0211 2012-05-01
- 打赏
- 举报
你好，请教高版本内核支持linuxthread 的问题，是这样的：
某个程序是在redhat 4(内核=2.6.9 glibc版本2.3.4)下面编译运行的，可能是使用linuxthread的问题，用在ubuntu（内核3.0.0，GLIBC为2.11.1）下面，就会出现GLIC或者libm.so.6找不到的问题，事实上只要GLIBC版本大于2.4都出现这样的问题. 正是2.4版本取消了linuxthread的支持.
请问怎么解决，可以编译高版本内核让其同时支持linuxthread和nptl吗？ 或者怎么修改配置，让其选择低版本的glibc libm 库文件？ 而其他程序依旧使用新的库文件
某个程序是在redhat 4(内核=2.6.9 glibc版本2.3.4)下面编译运行的，可能是使用linuxthread的问题，用在ubuntu（内核3.0.0，GLIBC为2.11.1）下面，就会出现GLIC或者libm.so.6找不到的问题，事实上只要GLIBC版本大于2.4都出现这样的问题. 正是2.4版本取消了linuxthread的支持.
请问怎么解决，可以编译高版本内核让其同时支持linuxthread和nptl吗？ 或者怎么修改配置，让其选择低版本的glibc libm 库文件？ 而其他程序依旧使用新的库文件
