Error: could not load library libz

[tbreloff]

As reported by @juanklopper: https://github.com/tbreloff/Plots.jl/issues/386#issuecomment-231576243

[jiahao]

reported on Mint 18

[haberdashPI]

Not sure if this is related, but I am getting a similar error on Mac OS X after running Pkg.update() today. Adding the following to my .juliarc.jl file resolved the problem.

push!(Libdl.DL_LOAD_PATH,"/usr/lib")

Though it seems odd to me that this would be necessary...

Here's the output before the fix:

using GZip
INFO: Precompiling module GZip.
ERROR: LoadError: LoadError: error compiling anonymous: could not load library "libz"
dlopen(libz.dylib, 1): image not found
Stacktrace:
 [1] include_from_node1(::String) at ./loading.jl:576
 [2] include(::String) at ./sysimg.jl:14
 [3] include_from_node1(::String) at ./loading.jl:576
 [4] include(::String) at ./sysimg.jl:14
 [5] anonymous at ./<missing>:2
while loading /Users/davidlittle/.julia/v0.6/GZip/src/zlib_h.jl, in expression starting on line 11
while loading /Users/davidlittle/.julia/v0.6/GZip/src/GZip.jl, in expression starting on line 75

[SimonDanisch]

just a heads up: JuliaLang/julia#22828 pretty much means that const _zlib = "libz" won't work on a lot of platforms, that only have e.g. libz.so.1 in their path.

[JBlaschke]

This seems to also be a problem on macOS 10.13.6 and Julia v0.7: https://github.com/FluxML/Flux.jl/pull/269#issuecomment-411896784 even though macOS doesn't have a libz.so.1 (instead libz is usr/lib/libz.dylib)

[SimonDanisch]

Yeah, that's exactly the issue! Anyways, just doing const _zlib = "libz" and then ccall((:func, _zlib), ...) is a very shaky way to rely on a binary dependency, so there are endless other ways to make this fail ;) Maybe consider using: https://github.com/bicycle1885/CodecZlib.jl, which is using BinaryProvider to make sure that libz is installed!

[staticfloat]

Just had another user run into this; they fixed it by installing zlib1g-dev on Ubuntu, but ever since https://github.com/JuliaLang/julia/pull/22828 we need a better answer for this. Personally, even though it's very likely that libz.so is already installed and available, I think it's best if we use e.g. BinaryProvider for this, so I think it's best if we just include the deps/build.jl from CodecZlib.jl and steal the binaries from that package for now. ;)

[jpsamaroo]

I'll add my +1 to using BinaryProvider as opposed to using system libz. On Gentoo, /usr/lib64/libz.so is actually a linker script (for whatever reason), and so I get an "Invalid ELF header" error anytime I try to precompile this package or, say, Libz.jl.

[JBlaschke]

The work around that I found for macOS was to set DYLD_LIBRARY_PATH to /usr/lib (in my case, I've installed libz using Homebrew which links everything into /usr/lib). More details here: https://github.com/FluxML/Flux.jl/issues/343#issuecomment-417878158

Note that this will let you precompile, but if you do anything else with that DYLD_LIBRARY_PATH setting, you'll crash the Julia interpreter. So you need to restart Julia and fiddle with the environment variables every time GZip is updated.

Therefore I also think the BinaryProvider is a better solution

[jcheong0428]

https://github.com/JuliaIO/GZip.jl/issues/54#issuecomment-361383213 worked for me. As a starter had to install Libdl first, and then push the library.

using Pkg
Pkg.add("Libdl")
using Libdl
push!(Libdl.DL_LOAD_PATH,"/usr/lib")

[shilangyu]

On fedora installing zlib-devel fixed it. Shouldn't external dependencies be listed in the README?