Избавление от git:/usr/local/lib/libz.so.1: информация о версии отсутствует (требуется git) "

Ответ 1

/usr/local предназначен для установки программ, скомпилированных локально администратором машины. Простые программы просто входят в /usr/local/bin и запускаются оттуда, помещая /usr/local/bin в переменную среды PATH. Это позволяет администратору предоставлять пользователям доступ к дополнительным командам, которые не включены в ОС. Там нет ничего, что можно было бы остановить от установки новых вещей в /usr/bin, но соглашение заключается в том, что /usr/bin управляется инструментами упаковки дистрибуторов ОС, а сохранение локального материала делает вещи немного менее запутанными.

Иногда локальной программе нужна библиотека, которая не предоставляется дистрибутором ОС, а библиотека переходит в /usr/local/lib, и все работает.

Когда есть конфликт версий - OS поставляется в libz.so версии X, но локальной программе требуется версия 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 версию и неправильно ведут себя. Вероятно, это можно устранить, удалив старую библиотеку. Программа /usr/local/bin, которая нуждалась в версии X + 1, найдет версию X + 2 в /usr/lib и будет работать нормально. Но только в том случае, если необходимость в более новой версии была причиной установки версии 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

Ответ 2

У меня есть DirectAdmin на моем сервере, и это это руководство решило мою проблему.

(скопировано со страницы)

Если вы видите ошибку

/usr/local/lib/libz.so.1: no version information available (required by python)

это связано с установленной версией libz. Причина для текущей версии связана с версией libz, которую требует libxml2. Более новая версия будет устранена, но из-за многих проблем, связанных с этим обновлением, мы вернулись к более старой версии libz и libxml2. Обратите внимание, что предупреждение не повредит ничего, поэтому его можно игнорировать.

Если вы все еще хотите обновить 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

Ответ 3

Похоже, вам нужно обновить свои предпосылки сборки.

Ответ 4

Этот метод работает для моего случая, добавьте следующую строку:.bash_profile:

LD_LIBRARY_PATH=/lib64:$LD_LIBRARY_PATH

затем запустите . ~/.bash_profile

Ответ 5

Экспортировать LD_LIBRARY_PATH с помощью пути git lib для устранения ошибки:

libz.so.1: no version information available