linux redhat5.5升级glibc报错 求助

图片说明

configure成功，make后报这个错误，不知道是什么问题？

http://bbs.csdn.net/topics/392014630

找不到limits.h头文件

1）提示找不到linux/limits.h，即/usr/include/linux/路径下没有limits.h这个文件，想到可能是少了某个包，接下来的任务就是找到生成这个路径下limits.h文件的包；
2）两个需要掌握的命令：dpkg -l 打印出系统中安装的所有包; dpkg -L 包名 打印出该包生成的所有文件及其路径。
3）考虑到一般的头文件都是由 “XXX-dev” 这样名字的包生成的。于是首先用命令dpkg -l |grep "dev" 标出那些候选，就几个;
4）然后将候选的几个包，用dpkg -L 包名 | grep "linux/limits.h" 打印结果，有结果的即为正确的包。最后定位到包 “linux-libc-dev:amd64” ;
5）以为没有这个包，于是直接安装 apt-get install linux-libc-dev:amd64。但发现并没有更新任何软件包。意思是安装了这个包，但是却没有在/usr/include/linux/路径下生成应该生成的limits.h文件。于是考虑将linux-libc-dev:amd64卸载后再重新安装。注意在卸载linux-libc-dev:amd64的时候还会卸载相关的几个包（大概7个左右，具体忘记了）。等卸载完成后，apt-get install linux-libc-dev:amd64，安装包，之后再将之前卸载的那几个相关的包一一安装上;
6）都安装好后再 make menuconfig

在安装HP硬件监控（hpasmcli）提示需要依赖Glibc-2.7，而本机的是Glibc-2.5，看来得升级Glibc了，可惜在升级时又出现了更多的依赖问题，想到在其他服务器上安装hpasmcli时很顺利，就想到将其他服务器的glibc库文件直接拷贝到本机尝试，涉及的文件有：
　　/lib/libc-2.5.so # 32位系统
　　/lib64/libc-2.5.so # 64位系统
　　因为我操作的服务器系统是64位的，故在覆盖/lib64/libc-2.5.so文件的瞬间，屏幕上立即报出大量内核错误，如下（其中host指代服务器主机名）：
　　Message from syslogd@ at Fri Apr 26 18:10:35 2013 。。。 host kernel： in6b rsp 00007fff8c0b8698 error 4 Message from syslogd@ at Fri Apr 26 18:10:35 2013 。。。 host kernel： init［1］： segfault at 0000000000000000 rip 00002b28b2052e6b rsp 00007fff8c0b8698 error 4 Message from syslogd@ at Fri Apr 26 18:10:35 2013 。。。 host last message repeated 17 times Message from syslogd@ at Fri Apr 26 18:10:35 2013 。。。 host kernel： init［1］： segfau6b rsp 00007fff8c0b8698 error 4 Message from syslogd@ at Fri Apr 26 18:10:35 2013 。。。 host kernel： init［16b rsp 00007fff8c0b8698 error 4
　　然后系统就崩溃了，无法再登录了。
　　紧急联系机房重启服务器，告知无法启动。
　　诶，亲手造成了此次事故呀！
　　要点：
　　glibc是gnu发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。由于 glibc 囊括了几乎所有的 UNIX 通行的标准，可以想见其内容包罗万象。
　　升级Glibc的忠告：不要在运行中的系统上安装 Glibc，否则将会导致系统崩溃，至少应当将新 Glibc 安装到其他的单独目录，以保证不覆盖当前正在使用的 Glibc。（我就无知的覆盖了，囧！）
　　解决方法：
　　赶赴机房吧，幸好我在替换前在目录/lib下保存了原来的库文件（libc-2.5.so.bak），使用Linux系统盘进入“救援模式”，将被替换的2个库文件恢复，重启系统就可以了;
　　系统正常启动了，就交给其他部门的同事去恢复数据吧。
　　上面就是Linux升级Glibc时系统奔溃的解决方法的介绍了，方法很简单，就要进入救援模式，将替换的库文件恢复回来就可以了，如果你在升级Glibc的时候不覆盖原有的Glibc就不会导致系统奔溃。