"/usr/bin/ld: cannot find -lz"

177,620

Solution 1

I had the exact same error, and like you, installing zlib1g-dev did not fix it. Installing lib32z1-dev got me past it. I have a 64 bit system and it seems like it wanted the 32 bit library.

Solution 2

For x64 install zlib1g-dev.

sudo apt-get install zlib1g-dev

I don't need all the x86 libs ;)

Solution 3

sudo apt-get install libz-dev in ubuntu.

Solution 4

I just encountered this problem and contrary to the accepted solution of "your make files are broken" and "host includes should never be included in a cross compile"

The android build includes many host executables used by the SDK to build an android app. In my case the make stopped while building zipalign, which is used to optimize an apk before installing on an android device.

Installing lib32z1-dev solved my problem, under Ubuntu you can install it with the following command:

sudo apt-get install lib32z1-dev

Solution 5

I had the exact same error, Installing zlib-devel solved my problem, Type the command and install zlib package.

On linux:

sudo apt-get install zlib*

On Centos:

sudo yum install zlib*

View more solutions

177,620

michael

Updated on July 11, 2020

Comments

michael almost 4 years

I am trying to compile Android source code under Ubuntu 10.04. I get an error saying,

/usr/bin/ld: cannot find -lz

Can you please tell me how can I fix it? What does cannot find -lz mean? Here's the full error message:

external/qemu/Makefile.android:1101: warning: overriding commands for target `external/qemu/android/avd/hw-config-defs.h'
external/qemu/Makefile.android:933: warning: ignoring old commands for target `external/qemu/android/avd/hw-config-defs.h'
host SharedLib: libneo_cgi (out/host/linux-x86/obj/lib/libneo_cgi.so)
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
make: *** [out/host/linux-x86/obj/lib/libneo_cgi.so] Error 1

And my GCC version output:

scheung@scheung-virtual-box:/media/EXTDIV/mydroid$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I already have the zlib1g-dev library installed:

$ sudo apt-get install zlib1g-dev 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
zlib1g-dev is already the newest version.

(I get that from this link.)

Qsiris over 11 years

It worked here with libz-dev (virtual package for zlib1g-dev) on Kubuntu 12.04 x64.
Marian over 9 years

Also helped me install/build lxml-3.4.0 for Python via pip on Ubuntu 14.04 LTS/trusty. Thanks!
Akshay Nalawade about 9 years

can confirm this worked for install lxml via pip on ubuntu 14.04
mknaf about 9 years

same for me as for mwjackson, although I got zlib1g-dev via the metapackage libz-dev, as was suggested in another answer.
cballenar almost 8 years

Could somebody shed some light into why is this necessary? I was able to install python-lxml in a virtual environment ONLY after installing this package. However if I tried to install it globally, I wouldn't have any problem at all. :\
DearVolt almost 7 years

If this doesn't work, try the static version zlib-static.
deinerson1 almost 6 years

Confirmed on amd64 Ubuntu 18.04 LTS, Bionic Beaver
ti7 over 4 years

Not certain about that case specifically, but broadly python-lxml requires logic contained in the zlib library which it cannot or simply doesn't provide itself. If it cannot reach the library, either because it's missing or some permissions barrier, it will be unable to build/function.
TrinitronX almost 4 years

@cballenar : Short answer: Dependencies! python-lxml depends on any package that Provides: libz-dev. C/C++ programs are compiled and linked against libraries which provide functions, routines, & data structures. Unix systems use .so, .a, .la files & Windows use .dll. These are compiled shared library files, that contain routines that other programs can link against and use to implement some functionality. For this example: libz implements data compression & decompression functions.
TrinitronX almost 4 years

@cballenar : Long answer / details (part 1): libz-dev is a virtual package on Ubuntu (verify this on your system with: apt show libz-dev). The other package zlib1g-dev provides libz-dev, which includes the shared library file /usr/lib/x86_64-linux-gnu/libz.a, and the C Header files /usr/include/zconf.h & /usr/include/zlib.h. You can view the package contents with: dpkg -L zlib1g-dev, which shows all the files it contains.
TrinitronX almost 4 years

@cballenar : Long answer (part 2): As mentioned, libz-dev (also in Debian) is provided by zlib1g-dev via the Debian Package Provides: libz-dev line in the Debian source package's debian/control file. This is how the apt packaging manager knows to resolve the python-lxml compile-time virtualenv package dependency on libz-dev via zlib1g-dev.
TrinitronX almost 4 years

@cballenar : Long answer (part 3): On Linux, there are multiple types of library files. They are mainly used with C/C++ programs, because they are the resulting output of the compilation process. These can be: shared (a.k.a dynamic) (. so), static (.a), and libtool convenience libraries (.la Note: These are not actually binary compiled libraries, but helper files that libtool uses internally).
TrinitronX almost 4 years

@cballenar : Long answer (part 4): These types of library files, along with C/C++ Header files (.h) are usually contained in *-dev type packages on Debian/Ubuntu. The notable exception being the libtool convenience library (.la) files. Debian recommends against including .la files due to issues with hidden dependencies.
TrinitronX almost 4 years

@cballenar : Long answer (part 5): The Debian project has a goal to remove .la files from their packaging for this reason, but you still might come across the .la files in some older *-dev packages. So, long story short: there's a lot of complexity hiding inside these Debian packages and they try to do their best at resolving dependencies for both runtime, compile time, and linking time. The first runtime dependency is handled by the actual shared library .so file.
TrinitronX almost 4 years

@cballenar : Long answer (part 6): In your case, libz-dev provides the types of files that are needed at either: compile or linker time. Many scripting language environment & version managers (e.g.: RVM, Virtualenv, Pyenv, etc...) actually compile and link against C/C++ libraries during their operations! This is because they manage separate versions and installations of Ruby, Python, etc... along with separate installs of any scripting language libraries (Ruby gems, Python pip packages, ...). These are managed in other directories, separated from the base system OS files.
TrinitronX almost 4 years

@cballenar : Long answer (part 7): At some point scripting language binaries need to be compiled and linked against the base system packages that provide compile and link time shared libraries. This is how the Scripting language itself is able to provide functionality such as provided by zlibg1 on LInux, or zlib on Windows / MacOS. In this way, the scripts are abstracted away from the base OS and platform using the scripting language. Yet, the actual binary code executed still lives in the base OS system libraries & packages. Virtualenv compiles & links during python install
z4nzi over 2 years

Helped me on a Debian 11 installation while compiling maloader