/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
