/usr/lib/libreadline.so.5: undefined symbol: PC 错误的处理方法

 

 

最近服务器挂掉将近一周，让X讯和VMware的运维人员给我处理，硬是搞不定。

最后还是Linux的厂商帮俺们搞定，结束我的苦逼酱油日子。

 

操作系统：Suse linux 11 64bit

硬件环境：就不多说了，反正是搭建在VM上面的。

 

一、现象：

1. 作为远程ssh连接，最基本的现象就是无法连接该虚拟主机了。

2. 在物理主机上使用vmware打开该虚拟机，会发现机器开机时候卡在第二屏（参看文末附件“现象01.png”）。

3. 使用F2快捷键进入命令行模式，是可以看到具体卡在哪里的（“现象02.png”）。

4. 提示信息如下：

/bin/sh: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: PC

 

 

二、分析：
1. 翻阅资料发现libreadline是系统自带的库，作为一个底层库，非常多的库都依赖于这个库。（具体参考连接：http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html ）

2. 因此在开机的时候系统bash启动某些服务的时候调用了这个库，而这个库里面有“PC”字样的符号：

3. 这个些符号是在保留libncurses或libtermcap 之中的：

4. 但是libreadline库默认是不包含这个libncurses库的（只依赖libc库）：

所以在启动的过程中，bash调用这个库（libreadline）之后就报错了。

 

 

 

三、解决：

1. 方法一（目前采取的办法）：将libreadline库删掉。

这个方法非常暴力，而且也是suse工程师采用的办法，仅仅将涉及的库文件删除掉就完事了。（目前1节点的时间已经被暴力干掉，2节点文件我保存了下来了，在/tmp目录，附件是两个文件，另外还有两个软链接，在windows下无法展现。）

但是该方法是有后遗症的：如果在编译某些程序的时候需要运行libreadline，则会提示无法通过。

并且后续运行，根据以往文献，gome等界面均是依赖该库文件的，因此gome等图形界面编辑器会无法使用（是否还有其它工具也是依赖于它则不得而知）

 

2. 方法二（风险系数较高，但如果要使用该库，只能用这方法）：重新编译libreadline，链接libncurses库。

步骤：

（0）将文件拷贝回/usr/local/lib 目录：  cp /tmp/libreadline* /usr/local/lib/   P.S.：严禁使用mv！（此步也可以不做）

（1） rpm -qa |grep readline   查看是否安装，以及安装版本。

（2）下载：readline-5.2.tar.gz 并解压。

（3）修改./shlib/Makefile.in   的  SHLIB_LIBS 为：   SHLIB_LIBS = -lncurses

（4） ./configure --prefix=/usr --with-ncurses           #生成Makefile

（5） make

（6）make install

（7）编译完成后查看是否已经链接进去： readelf -a /usr/local/lib/libreadline.so.5 | grep NEEDED

 

 

欢迎指正。

参考文章： http://blog.chinaunix.net/uid-20587912-id-405184.html