对于我尝试运行的每个git命令,我收到此消息.例:
stewie:~# git --version
git: /usr/local/lib/libz.so.1: no version information available (required by git)
git version 1.7.11.4
我怎么能摆脱这个？
编辑1:
试图更新zlib1g:
stewie:/tmp# apt-get install zlib1g
Reading package lists... Done
Building dependency tree
Reading state information... Done
zlib1g is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
编辑2:
我在Debian Lenny(5),不幸的是,使用apt-get并不那么容易.
Ala*_*rry 17
/ usr/local用于安装由机器管理员在本地编译的程序.简单的程序只需进入/ usr/local/bin,然后将/ usr/local/bin放入PATH环境变量中即可运行.这允许管理员为用户提供对操作系统中未包含的其他命令的访问权限.没有什么能阻止root用户在/ usr/bin中安装新东西,但惯例是/ usr/bin由OS经销商的打包工具管理,并且保持本地内容分离会让事情变得更加混乱.
有时本地程序需要一个OS分销商不提供的库,并且库进入/ usr/local/lib并且一切正常.
当存在版本冲突时 - 操作系统提供了版本X的libz.so,但是本地程序需要libz.so版本X + 1或者需要使用特殊选项编译libz.so - 事情开始变得复杂.首先在/ usr/local/lib中安装较新的库可能没问题.
每个程序都基于查找库/etc/ld.so.conf,如果/ usr/lib在那里优先,/ usr/local程序将找不到他们需要的新库.所以/ usr/local/lib通常是优先考虑的.寻找较新库的较旧程序通常不是问题,因为库是向后兼容的.
多年后,在几次操作系统升级之后,/ usr/lib中的库现在是版本X + 2,而/ usr/local/lib中的库仍然是版本X + 1,现在来自/ usr/bin的程序正在加载旧的/ usr/local/lib版本,行为不端.这可以通过删除旧库来修复.需要版本X + 1的/ usr/local/bin程序将在/ usr/lib中找到版本X + 2并且工作正常.但只有当需要更新的版本才是首先在本地安装X + 1版本的原因.
要在删除之前探测潜在问题,请在/ usr/local下查找使用libz的任何内容.
ldd /usr/local/bin/* /usr/local/sbin/* | less +/libz
如果您发现任何引用libz的内容,请尝试运行它LD_LIBRARY_PATH=/usr/lib以确保它仍然有效.假设没有任何中断,删除本地libz文件(通过将它们移动到备份位置,以便您可以撤消此操作,如果必须)
mkdir /root/local-libz-backup
mv /usr/local/lib/libz* /root/local-libz-backup
ldconfig