场景： 本打算在centos6.5系统安装proxychains，由于软件版本太高(适合centos/redhat7系列)，安装时报错： ,然后这时，我做了个很愚蠢的操作，我从其他系统找到这个库文件，
场景：
本打算在centos6.5系统安装proxychains，由于软件版本太高(适合centos/redhat7系列)，安装时报错：
,然后这时，我做了个很愚蠢的操作，我从其他系统找到这个库文件，发现是个软链接，真正的库文件为libc-2.17.so，但忽略了我现在用的系统版本都是7版本以上，就把这个文件直接拷到我的6.5版本测试环境中，并且做了软链接；刚开始没事，但再次安装proxychains，还是报同样的错误，完全没有生效，（在这里提醒下，lib文件是依赖系统版本的，不能随便更改或替换），于是，想到可能是版本太高的问题，从官网下载了低版本的，轻松安装上了，接下来的可怕的一幕发生了：
【relocation error: /usr/lib64/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file
ld-linux-x86-64.so.2 with link time reference】输入任何命令都提示这个错误（基本的cd、pwd等命令还是可以用的），看现象应该是更改了我的环境变量，导致大部分依赖这个库的命令都不能正常使用，然后开始上网各种查，还是不行，尽管网上说不能重启，重启后导致无法进入系统，但也没办法，抱着试一试的心态，希望重启后可以恢复；于是重启，悲剧的一幕再次发生：
然后，根据报错信息继续找解决办法，然后知道，导致这种现象的操作有很多种，原因不同，解决办法也不同，没办法只能自己想法了。
解决办法：重新制作系统启动盘 ，开机进入系统拯救模式，df -h 看了下硬盘信息，进入到原系统的挂载目录下，/mnt/sysimage，然后再进入到/usr/lib64目录下，删掉了我新建的哪两个库文件，重启，。。。。
终于看到熟悉的登陆界面了。
注：虽然这个方法这适合自己，但思路应该都一样，以后遇到这种现象，还是要回想自己的操作，然后回退到操作之前的状态，应该可以解决。
再次声明，库文件依赖系统版本，依赖软件版本，不要随便更改或替换。
