摆脱“git：/usr/local/lib/libz.so.1：没有可用的版本信息（git需要）”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/11961400/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Getting rid of "git: /usr/local/lib/libz.so.1: no version information available (required by git)"
提问by dmmd
For every git command I try to run, I get this message. Example:
对于我尝试运行的每个 git 命令，我都会收到此消息。例子：
stewie:~# git --version
git: /usr/local/lib/libz.so.1: no version information available (required by git)
git version 1.7.11.4
How can I get rid of this?
我怎样才能摆脱这个？
Edit 1:
编辑1：
Trying to update zlib1g:
尝试更新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.
Edit 2:
编辑2：
I'm on Debian Lenny (5), so, unfortunately, using apt-getisn't that easy.
我在 Debian Lenny (5) 上，所以，不幸的是，使用apt-get并不是那么容易。
回答by Alan Curry
/usr/local is meant to be used for installation of programs compiled locally, by the machine's administrator. Simple programs just go into /usr/local/bin and are run from there by putting /usr/local/bin into the PATHenvironment variable. This allows the administrator to provide the users access to additional commands, which aren't included in the OS. There's nothing stopping root from installing new things into /usr/bin but the convention is that /usr/bin is managed by the OS distributor's packaging tools, and keeping local stuff separate makes things a little less confusing.
/usr/local 用于安装本地编译的程序，由机器管理员使用。简单的程序只需进入 /usr/local/bin 并通过将 /usr/local/bin 放入PATH环境变量从那里运行。这允许管理员为用户提供对其他命令的访问权限，这些命令不包含在操作系统中。没有什么能阻止 root 将新东西安装到 /usr/bin 中，但惯例是 /usr/bin 由操作系统分销商的打包工具管理，将本地内容分开会使事情变得不那么混乱。
Sometimes a local program needs a library that isn't provided by the OS distributor, and the library goes into /usr/local/lib and everything works.
有时本地程序需要一个不是由操作系统发行商提供的库，而该库进入 /usr/local/lib 并且一切正常。
When there's a version conflict - the OS supplied libz.so of version X but a local program needs libz.so version X+1 or needs libz.so to be compiled with a special option - things start to get complicated. Installing the newer library in /usr/local/lib is probably OK at first.
当存在版本冲突时 - 操作系统提供了版本 X 的 libz.so 但本地程序需要 libz.so 版本 X+1 或需要使用特殊选项编译 libz.so - 事情开始变得复杂。在 /usr/local/lib 中安装较新的库一开始可能没问题。
Every program looks for libraries based on /etc/ld.so.confand if /usr/lib is given priority there, the /usr/local programs won't find the newer library that they need. So /usr/local/lib is usually given priority. Older programs finding a newer library is usually not a problem because the libraries are backward-compatible.
每个程序查找基于的库/etc/ld.so.conf，如果 /usr/lib 在那里被赋予优先级，则 /usr/local 程序将找不到他们需要的较新的库。所以 /usr/local/lib 通常被优先考虑。较旧的程序找到较新的库通常不是问题，因为这些库是向后兼容的。
Years later, after a few OS upgrades, the library in /usr/lib is now version X+2 and the one in /usr/local/lib is still version X+1, and now programs from /usr/bin are loading the old /usr/local/lib version, and misbehaving. This can probably be fixed by removing the old library. The /usr/local/bin program that needed version X+1 will find version X+2 in /usr/lib and work fine. But only if the need for a newer version was the reason for installing version X+1 locally in the first place.
多年后，经过几次操作系统升级，/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 的原因。
To probe for potential problems before doing the removal, look for anything under /usr/local that uses libz.
要在删除之前探测潜在问题，请在 /usr/local 下查找使用 libz 的任何内容。
ldd /usr/local/bin/* /usr/local/sbin/* | less +/libz
If you find anything that references libz, try running it with LD_LIBRARY_PATH=/usr/libto make sure it still works. Assuming nothing breaks, remove the local libz files (by moving them to a backup location so you can undo this if you have to)
如果您发现任何引用 libz 的内容，请尝试运行它LD_LIBRARY_PATH=/usr/lib以确保它仍然有效。假设没有中断，删除本地 libz 文件（通过将它们移动到备份位置，以便您可以在必要时撤消此操作）
mkdir /root/local-libz-backup
mv /usr/local/lib/libz* /root/local-libz-backup
ldconfig
回答by Rutger van Baren
I have DirectAdmin on my server and this this guidesolved my problem.
我的服务器上有 DirectAdmin，本指南解决了我的问题。
(copied from page)
（复制自页面）
If you see the error
如果您看到错误
/usr/local/lib/libz.so.1: no version information available (required by python)
it has to do with the version of libz installed. The reason for the current version has to do with the version of libz that libxml2 requires. A newer version of both will resolve the issue, but due to many reported issues with this update, we reverted to the older version of libz and libxml2. Note that the warning is not going to hurt anything, so it can be ignored.
它与安装的 libz 版本有关。当前版本的原因与 libxml2 所需的 libz 版本有关。两者的较新版本将解决该问题，但由于此更新报告的许多问题，我们恢复到旧版本的 libz 和 libxml2。请注意，警告不会伤害任何东西，因此可以忽略它。
If you still wish to update libz and libxml2 to their newer versions to avoid the message, type:
如果您仍希望将 libz 和 libxml2 更新到它们的较新版本以避免出现该消息，请键入：
cd /usr/local/directadmin/custombuild
./build update
perl -pi -e 's/zlib:1.2.3:.*/zlib:1.2.5:/' versions.txt
perl -pi -e 's/libxml2:2.7.6:.*/libxml2:2.7.8:/' versions.txt
./build update_data
./build zlib
./build libxml2
./build php n
回答by Steven Yang
This method works for my case, add the following line your .bash_profile:
此方法适用于我的情况，在 .bash_profile 中添加以下行：
LD_LIBRARY_PATH=/lib64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/lib64:$LD_LIBRARY_PATH
then run . ~/.bash_profile
然后运行 . ~/.bash_profile
回答by Adam Dymitruk
Looks like you need to update your build prerequisites.
看起来您需要更新构建先决条件。
回答by cvaleti
Export LD_LIBRARY_PATHwith the git lib path for resolving the error:
LD_LIBRARY_PATH使用 git lib 路径导出以解决错误：
libz.so.1: no version information available
