Home/ Questions/Q 8383363
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T17:08:45+00:00

For every git command I try to run, I get this message. Example: stewie:~#

  • 0

For every git command I try to run, I get this message. Example:

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:

Trying to update 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:

I’m on Debian Lenny (5), so, unfortunately, using apt-get isn’t that easy.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    /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 PATH environment 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.

    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.

    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.

    Every program looks for libraries based on /etc/ld.so.conf and 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.

    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.

    To probe for potential problems before doing the removal, look for anything under /usr/local that uses 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/lib to 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)

    mkdir /root/local-libz-backup
mv /usr/local/lib/libz* /root/local-libz-backup
ldconfig
    • 0