error loading ZLIB (wrong libz library being linked) #151

bjarthur · 2015-07-31T14:03:22Z

there have been many reported before, i know it must be annoying, but with i'm having problems with the latest version of anaconda (python 2.7.10, matplotlib 1.4.3) and julia 0.3.11. python works fine by itself, but within julia i get an error related to libz. ideas? thanks.

julia> using PyCall

julia> @pyimport matplotlib.pyplot as plt
ERROR: PyError (:PyImport_ImportModule) <type 'exceptions.ImportError'>
ImportError("/lib64/libz.so.1: version `ZLIB_1.2.3.4' not found (required by /usr/local/anaconda/lib/python2.7/site-packages/matplotlib/../../.././libpng16.so.16)",)
  File "/usr/local/anaconda/lib/python2.7/site-packages/matplotlib/pyplot.py", line 27, in <module>
    import matplotlib.colorbar
  File "/usr/local/anaconda/lib/python2.7/site-packages/matplotlib/colorbar.py", line 34, in <module>
    import matplotlib.collections as collections
  File "/usr/local/anaconda/lib/python2.7/site-packages/matplotlib/collections.py", line 27, in <module>
    import matplotlib.backend_bases as backend_bases
  File "/usr/local/anaconda/lib/python2.7/site-packages/matplotlib/backend_bases.py", line 56, in <module>
    import matplotlib.textpath as textpath
  File "/usr/local/anaconda/lib/python2.7/site-packages/matplotlib/textpath.py", line 19, in <module>
    import matplotlib.font_manager as font_manager
  File "/usr/local/anaconda/lib/python2.7/site-packages/matplotlib/font_manager.py", line 58, in <module>
    from matplotlib import ft2font

 in pyerr_check at /tier2/genie/BenArthur/julia-0.3.11/share/julia/site/v0.3/PyCall/src/exception.jl:58
 in pyimport at /tier2/genie/BenArthur/julia-0.3.11/share/julia/site/v0.3/PyCall/src/PyCall.jl:91

julia> Pkg.installed()["PyCall"]
v"0.8.2"

julia> VERSION
v"0.3.11"

julia> 


[arthurb@h09u16 BenArthur]$ which python
/usr/local/anaconda/bin/python

[arthurb@h09u16 BenArthur]$ python
Python 2.7.10 |Anaconda 2.1.0 (64-bit)| (default, May 28 2015, 17:02:03) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://binstar.org
>>> import matplotlib
>>> matplotlib.__version__
'1.4.3'
>>>

The text was updated successfully, but these errors were encountered:

stevengj · 2015-07-31T15:06:04Z

Is there a different version of libz somewhere else on your system? e.g. in /usr/local/anaconda/lib/ ?

Maybe just adding the right path to the DYLD_LIBRARY_PATH environment variable will fix it? (Although I've never had to fuss with this path manually for PyPlot before on other MacOS systems.)

bjarthur · 2015-07-31T16:34:39Z

thanks. export LD_LIBRARY_PATH=/usr/local/anaconda/lib:$LD_LIBRARY_PATH fixed it. but why would this be necessary?

stevengj · 2015-07-31T21:22:32Z

You have multiple versions of libz installed, and libpython needs to find the right one...

Maybe the python executable was forcibly linked to the libz in the anaconda directory, but since we are manually loading libpython we don't benefit from this?

Frustrating.... I need to figure out a way to automate this, but setting the environment variable is dangerous because it can effect other child processes.

stevengj · 2015-09-24T19:58:07Z

You can use Miniconda via the Conda.jl package now. Just do:

ENV["PYTHON"]=""
Pkg.update()
Pkg.build("PyCall")
using PyPlot

and it should install and use matplotlib in the "private" Julia miniconda distribution set up by Conda.

longqian95 · 2015-10-15T06:16:41Z

I found this problem again after upgrading to the newest version. There is no problem if just running " LD_LIBRARY_PATH=~/.julia/v0.4/Conda/deps/usr/lib julia". It looks like even in the private Conda enviroment, the matplotlib still try to call /lib64/libz.so.1. Do you have any idea to fix that?

stevengj · 2015-10-15T20:12:03Z

I'm not sure. Maybe Conda could modify the LD_LIBRARY_PATH environment, but changing environment variables is risky to do automatically because it can affect too many other things (e.g. child processes).

longqian95 · 2015-10-30T04:37:43Z

Yes, you are right. Modifying the LD_LIBRARY_PATH can make PyPlot to work, but breaks the other packages such as RCall in my system. I also found that if running the matplotlib directly in python at the Conda environment, there is no problem. So I suspect PyCall or julia itself changed the environment and make matplotlib go to /lib64/ to load share libraries.

stevengj · 2016-06-29T13:44:34Z

Note that a version of this problem this also shows up with Conda's matplotlib, as described in #229. It's basically the same issue: there are multiple libz libraries on the system, but the runtime linker is loading the wrong one for Matplotlib's libpng.

Probably in that case there is an appropriate libz version already in /home/<USERNAME>/.julia/v0.4/Conda/deps/usr/lib or similar, and again you need to prepend this to LD_LIBRARY_PATH.

cc: @Luthaf

Luthaf · 2016-06-29T14:04:25Z

Conda.jl only touch the environment to remove any reference to others conda installations. So it might be either Python or Julia which is doing something strange when loading shared libraries.

stevengj · 2016-06-29T14:16:38Z

@Luthaf, I don't think we are doing anything strange, it is just that by default the system loads libz from /usr/lib first. Mucking with LD_LIBRARY_PATH is a workaround that users can do to avoid this.

I'm not sure what a good general solution would be, although hopefully the failure will go away once distros ship a newer libz.

Luthaf · 2016-06-29T14:30:32Z

Maybe we should just follow what Python is doing ? (it look like is doing something different, there is no libz dependency for libpython.so)

stevengj · 2017-03-16T23:45:31Z

As was noted on the mailing list, you can avoid mucking with LD_LIBRARY_PATH via

LD_PRELOAD=${HOME}/.julia/v0.5/Conda/deps/usr/lib/libz.so julia

An even better option might be for PyPlot to explicitly dlopen this library before loading the matplotlib module.

RalphAS · 2017-03-17T03:07:51Z

Note that the julia executable itself links to libz.so (at least on Linux). This pre-empts the normal preference of Conda's libpng.so for linking to its sibling, hence the problem in this issue. Using dlopen (per @stevengj) may be tricky if parts of the old library are already mapped and linked.

Another possibility (for future releases) is to build Julia against an included (recent) libz.so. That is already done for libstdc++.so, for example. Incidentally, the latter library choice would be overridden by pointing LD_LIBRARY_PATH into, say, a full Anaconda install: that is an accident waiting to happen.

stevengj · 2017-03-17T17:15:17Z

You're right; it looks like Julia links libz because of libgit2, mbedtls, and maybe curl.

this circumvents PyPlot issue 151, see JuliaPy/PyPlot.jl#151

axsk · 2017-10-11T10:57:42Z

I encounter this problem as well since switching to 0.6.0.
The LD_PRELOAD trick works, but is annoying anyhow.

On 0.5.2 everything runs smoothly without intervention.
I use the Conda python version in both setups.

CorySimon · 2017-11-08T01:36:44Z

I encounter this problem as well since switching to 0.6.0.

stevengj · 2017-11-08T13:19:42Z

I wish there were a better solution (other than re-compiling Julia or Matplotlib).

zekeriyasari · 2017-11-21T08:23:13Z

Following steps solved my problem:

Download zlib version 1.2.9
Uncompress the file
cd to zlib-1.2.9
Run
./configure; make; make install
libz.so.1.2.9 is installed under /usr/local/lib
cd to /lib/x86_64-linux-gnu
Give the link
ln -s -f /usr/local/lib/libz.so.1.2.9/lib libz.so.1

BoundaryValueProblems · 2017-11-28T23:30:44Z

@zekeriyasari I followed your method on my linux machine. First of all the line:
ln -s -f /usr/local/lib/libz.so.1.2.9/lib libz.so.1 should be perhaps ln -s -f /usr/local/lib/libz.so.1.2.9 libz.so.1
But, it's too dangerous to replace /lib/x86_64-linux-gnu/libz.so.1. It works for a while, but then I cannot even login to my machine since many programs depend on libz.so.1. We need another solution.

stevengj · 2017-11-29T04:26:39Z

@BoundaryValueProblems, the non-dangerous solutions are either using LD_PRELOAD or recompiling Julia...

stevengj · 2017-11-29T04:34:18Z

On Linux, maybe it would be better to use the distro's own matplotlib, which presumably links to /usr/lib/libz.so, rather than Conda's?

Alternatively maybe if we dlopen /usr/lib/libpng.so we can force Conda to use the distro's libpng (which depends on the distro's libz) rather than its own?

v-i-s-h · 2018-03-23T05:56:54Z

I'm in elementaryOS 0.4.1 and having julia 0.6.2 built from source. I tried with the following in bashrc

export LD_LIBRARY_PATH=/home/vish/.julia/v0.6/Conda/deps/usr/lib:$LD_LIBRARY_PATH
export PATH="/opt/julialang/v0.6.2-native/bin:$PATH"

When I try to load PyPlot in julia, I get

vish@eliteone:~$ julia
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: https://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.6.2 (2017-12-13 18:08 UTC)
 _/ |\__'_|_|_|\__'_|  |  
|__/                   |  x86_64-linux-gnu

julia> Pkg.build( "PyPlot" )
INFO: Building Conda
INFO: Building PyCall
Solving environment: done

# All requested packages already installed.

INFO: PyCall is using /home/vish/.julia/v0.6/Conda/deps/usr/bin/python (Python 2.7.14) at /home/vish/.julia/v0.6/Conda/deps/usr/bin/python, libpython = /home/vish/.julia/v0.6/Conda/deps/usr/lib/libpython2.7
INFO: /home/vish/.julia/v0.6/PyCall/deps/deps.jl has not changed
INFO: /home/vish/.julia/v0.6/PyCall/deps/PYTHON has not changed

julia> 
julia> using PyPlot

julia> plot( 1:10 )
ERROR: PyError (ccall(@pysym(:PyObject_Call), PyPtr, (PyPtr, PyPtr, PyPtr), o, arg, C_NULL)) <type 'exceptions.RuntimeError'>
RuntimeError('Julia exception: ReadOnlyMemoryError()',)
  File "/home/vish/.julia/v0.6/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/pyplot.py", line 3244, in plot
    ax = gca()
  File "/home/vish/.julia/v0.6/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/pyplot.py", line 984, in gca
    return gcf().gca(**kwargs)
  File "/home/vish/.julia/v0.6/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/pyplot.py", line 601, in gcf
    return figure()

Stacktrace:
 [1] pyerr_check at /home/vish/.julia/v0.6/PyCall/src/exception.jl:56 [inlined]
 [2] pyerr_check at /home/vish/.julia/v0.6/PyCall/src/exception.jl:61 [inlined]
 [3] macro expansion at /home/vish/.julia/v0.6/PyCall/src/exception.jl:81 [inlined]
 [4] #_pycall#67(::Array{Any,1}, ::Function, ::PyCall.PyObject, ::UnitRange{Int64}, ::Vararg{UnitRange{Int64},N} where N) at /home/vish/.julia/v0.6/PyCall/src/PyCall.jl:653
 [5] _pycall(::PyCall.PyObject, ::UnitRange{Int64}, ::Vararg{UnitRange{Int64},N} where N) at /home/vish/.julia/v0.6/PyCall/src/PyCall.jl:641
 [6] #pycall#71(::Array{Any,1}, ::Function, ::PyCall.PyObject, ::Type{PyCall.PyAny}, ::UnitRange{Int64}, ::Vararg{UnitRange{Int64},N} where N) at /home/vish/.julia/v0.6/PyCall/src/PyCall.jl:675
 [7] pycall(::PyCall.PyObject, ::Type{PyCall.PyAny}, ::UnitRange{Int64}, ::Vararg{UnitRange{Int64},N} where N) at /home/vish/.julia/v0.6/PyCall/src/PyCall.jl:675
 [8] #plot#85(::Array{Any,1}, ::Function, ::UnitRange{Int64}, ::Vararg{UnitRange{Int64},N} where N) at /home/vish/.julia/v0.6/PyPlot/src/PyPlot.jl:171
 [9] plot(::UnitRange{Int64}, ::Vararg{UnitRange{Int64},N} where N) at /home/vish/.julia/v0.6/PyPlot/src/PyPlot.jl:168

julia> exit()

signal (11): Segmentation fault
while loading no file, in expression starting on line 0
unknown function (ip: 0x7f34450db589)
_ZN4llvm2cl19generic_parser_base10findOptionEPKc at /opt/julialang/v0.6.2-native/bin/../lib/libLLVM-3.9.so (unknown line)
unknown function (ip: 0x7f3443b4b08c)
_ZN4llvm19MachinePassRegistry6RemoveEPNS_23MachinePassRegistryNodeE at /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1 (unknown line)
__run_exit_handlers at /build/glibc-Cl5G7W/glibc-2.23/stdlib/exit.c:82
exit at /build/glibc-Cl5G7W/glibc-2.23/stdlib/exit.c:104
jl_exit at /opt/julialang/src/julia/src/jl_uv.c:552
exit at ./initdefs.jl:22
unknown function (ip: 0x7f343e73f7f8)
jl_call_fptr_internal at /opt/julialang/src/julia/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /opt/julialang/src/julia/src/julia_internal.h:358 [inlined]
jl_apply_generic at /opt/julialang/src/julia/src/gf.c:1926
do_call at /opt/julialang/src/julia/src/interpreter.c:75
eval at /opt/julialang/src/julia/src/interpreter.c:242
jl_interpret_toplevel_expr at /opt/julialang/src/julia/src/interpreter.c:34
jl_toplevel_eval_flex at /opt/julialang/src/julia/src/toplevel.c:577
jl_toplevel_eval_in at /opt/julialang/src/julia/src/builtins.c:496
eval at ./boot.jl:235
unknown function (ip: 0x7f343e5878af)
jl_call_fptr_internal at /opt/julialang/src/julia/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /opt/julialang/src/julia/src/julia_internal.h:358 [inlined]
jl_apply_generic at /opt/julialang/src/julia/src/gf.c:1926
eval_user_input at ./REPL.jl:66
unknown function (ip: 0x7f343e608f1f)
jl_call_fptr_internal at /opt/julialang/src/julia/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /opt/julialang/src/julia/src/julia_internal.h:358 [inlined]
jl_apply_generic at /opt/julialang/src/julia/src/gf.c:1926
macro expansion at ./REPL.jl:97 [inlined]
#1 at ./event.jl:73
unknown function (ip: 0x7f34235572bf)
jl_call_fptr_internal at /opt/julialang/src/julia/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /opt/julialang/src/julia/src/julia_internal.h:358 [inlined]
jl_apply_generic at /opt/julialang/src/julia/src/gf.c:1926
jl_apply at /opt/julialang/src/julia/src/julia.h:1424 [inlined]
start_task at /opt/julialang/src/julia/src/task.c:267
unknown function (ip: 0xffffffffffffffff)
Allocations: 7568252 (Pool: 7566574; Big: 1678); GC: 15
Segmentation fault (core dumped)
vish@eliteone:~$

I'm not able to use PyPlot at all and more weird is when I exit julia, it goes to a SEG_FAULT!!

EDIT

The problem appears to be related to anaconda's version of Qt and Pyplot. Easy solution is to use a different backend for GUI. This method works

using PyCall
pygui(:tk)
using PyPlot

For now, I'm putting first two lines in ~/.juliarc.jl and calling julia with LD_PRELOAD=${HOME}/.julia/v0.6/Conda/deps/usr/lib/libz.so julia

per last comment in [https://github.com/JuliaPy/PyPlot.jl/issues/151](https://github.com/JuliaPy/PyPlot.jl/issues/151)

urlicht · 2018-05-24T14:16:08Z

Still having this issue on Ubuntu 16.04, julia 0.6.2. Have tried many solutions and nothing worked. Finally, @SimonEnsemble's alias julia='LD_PRELOAD=${HOME}/.julia/v0.6/Conda/deps/usr/lib/libz.so julia solution worked! Thanks!

However, putting that on the ~/.bashrc didn't do the magic for Jupyter kernel. In case yop're having the same issue, adding the following env dictionary solved the issue:
"env": {"LD_PRELOAD":"/home/username/.julia/v0.6/Conda/deps/usr/lib/libz.so"}

emcangi · 2018-05-30T19:09:41Z

The solutions in this thread WERE working for me (including Jupyter kernel) but abruptly stopped for no apparent reason. I had to use the libz.so located in ${HOME}/anaconda3/lib.

@urlicht, what is this env dictionary and where should it be added?

urlicht · 2018-05-30T20:07:14Z

@emcangi It's your Julia kernel file. jupyter --path should print out the paths, but mine is located in ~/.local/share/jupyter/kernels/julia-0.6
Simply add a line like this with the correct path:"env": {"LD_PRELOAD":"/home/username/.julia/v0.6/Conda/deps/usr/lib/libz.so"}

emcangi · 2018-05-30T20:17:10Z

@urlicht thanks, that does the trick! if anyone else does this and it breaks their julia kernel, don't forget the separating comma ;)

stevengj · 2018-06-12T17:15:47Z

This issue should now be fixed in Julia 0.6.3, thanks to JuliaLang/julia#26888, right?

pierre-haessig · 2018-06-13T07:43:55Z

@stevengj Yes indeed, on my Debian stable system, using Anaconda and the official 0.6.3 Julia binary, PyPlot is working again. Thanks!

mzaffalon · 2018-06-13T08:46:55Z

It works on CentOS 7 64 bits with Anaconda and the official 0.6.3 Julia binary.

stevengj · 2018-06-13T16:18:13Z

Hooray!

oxinabox · 2018-06-18T07:52:51Z

switching over to 0.6.3 seems to have fixed this for me too (Yay).
Should REQUIRE be updated to say 0.6.3?
Though maybe that will nto do much without editting all releases tagged on Metadata...

stevengj · 2018-06-18T12:00:33Z

No, because 0.6.3 is not required per se, it just avoids a particular conflict on a particular set of platforms.

emcangi · 2018-06-19T17:22:30Z

I'm actually still getting the same error after upgrading to 0.6.3... could something be wrong with my anaconda installation?

stevengj · 2018-06-19T17:25:40Z

What does versioninfo() report in Julia?

emcangi · 2018-06-19T17:31:45Z

Julia Version 0.6.3
Commit d55cadc350 (2018-05-28 20:20 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, sandybridge)

This is on redhat. Julia reports that ENV["PYTHON"] doesn't exist, although the error message tells me that it is configured to use the python located in /myhomefolder/anaconda3/bin. matplotlib is installed in /myhomefolder/anaconda3/lib/python3.6/site-packages.

emcangi · 2018-06-19T17:37:00Z

Actually, new information: It works fine if I start a julia prompt and then enter using PyPlot. It also works fine if I run a script that includes using PyPlot at the top. it only throws the error if I run the script that also includes using HDF5.

So this is an error with HDF5 instead, I didn't notice it was being called first in my script. It looks like the user base has already noticed it: JuliaIO/HDF5.jl#485

Disregard this request!

deszoeke · 2021-10-19T23:49:40Z

The ZLIB version issue is back in the CentOS julia v1.6.3 nalimilan Copr build.

bash-4.2$ LD_PRELOAD="/home/server/pi/homes/sdeszoek/.julia/conda/3/lib/libz.so.1.2.11" julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.6.3 (2021-09-23)
 _/ |\__'_|_|_|\__'_|  |  nalimilan/julia Copr build
|__/                   |

julia> ENV["PYTHON"]=""
""

(@v1.6) pkg> build PyCall
    Building Conda ─→ `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/299304989a5e6473d985212c28928899c74e9421/build.log`
    Building PyCall → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/169bb8ea6b1b143c5cf57df6d34d022a7b60c6db/build.log`

julia> using PyPlot
[ Info: Installing matplotlib via the Conda matplotlib package...
[ Info: Running `conda install -y matplotlib` in root environment
Collecting package metadata (current_repodata.json): done
Solving environment: done

# All requested packages already installed.

ERROR: InitError: PyError (PyImport_ImportModule

The Python package matplotlib could not be imported by pyimport. Usually this means
that you did not install matplotlib in the Python version being used by PyCall.

PyCall is currently configured to use the Julia-specific Python distribution
installed by the Conda.jl package.  To install the matplotlib module, you can
use `pyimport_conda("matplotlib", PKG)`, where PKG is the Anaconda
package the contains the module matplotlib, or alternatively you can use the
Conda package directly (via `using Conda` followed by `Conda.add` etcetera).

Alternatively, if you want to use a different Python distribution on your
system, such as a system-wide Python (as opposed to the Julia-specific Python),
you can re-configure PyCall with that Python.   As explained in the PyCall
documentation, set ENV["PYTHON"] to the path/name of the python executable
you want to use, run Pkg.build("PyCall"), and re-launch Julia.

) <class 'ImportError'>
ImportError("/lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /home/server/pi/homes/sdeszoek/.julia/conda/3/lib/python3.7/site-packages/matplotlib/../../.././libpng16.so.16)")
  File "/home/server/pi/homes/sdeszoek/.julia/conda/3/lib/python3.7/site-packages/matplotlib/__init__.py", line 157, in <module>
    _check_versions()
  File "/home/server/pi/homes/sdeszoek/.julia/conda/3/lib/python3.7/site-packages/matplotlib/__init__.py", line 142, in _check_versions
    from . import ft2font

Stacktrace:
 [1] pyimport(name::String)
   @ PyCall ~/.julia/packages/PyCall/BD546/src/PyCall.jl:550
 [2] pyimport_conda(modulename::String, condapkg::String, channel::String)
   @ PyCall ~/.julia/packages/PyCall/BD546/src/PyCall.jl:714
 [3] pyimport_conda
   @ ~/.julia/packages/PyCall/BD546/src/PyCall.jl:707 [inlined]
 [4] __init__()
   @ PyPlot ~/.julia/packages/PyPlot/XaELc/src/init.jl:185
during initialization of module PyPlot

caused by: PyError (PyImport_ImportModule

The Python package matplotlib could not be imported by pyimport. Usually this means
that you did not install matplotlib in the Python version being used by PyCall.

PyCall is currently configured to use the Julia-specific Python distribution
installed by the Conda.jl package.  To install the matplotlib module, you can
use `pyimport_conda("matplotlib", PKG)`, where PKG is the Anaconda
package the contains the module matplotlib, or alternatively you can use the
Conda package directly (via `using Conda` followed by `Conda.add` etcetera).

Alternatively, if you want to use a different Python distribution on your
system, such as a system-wide Python (as opposed to the Julia-specific Python),
you can re-configure PyCall with that Python.   As explained in the PyCall
documentation, set ENV["PYTHON"] to the path/name of the python executable
you want to use, run Pkg.build("PyCall"), and re-launch Julia.

) <class 'ImportError'>
ImportError("/lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /home/server/pi/homes/sdeszoek/.julia/conda/3/lib/python3.7/site-packages/matplotlib/../../.././libpng16.so.16)")
  File "/home/server/pi/homes/sdeszoek/.julia/conda/3/lib/python3.7/site-packages/matplotlib/__init__.py", line 157, in <module>
    _check_versions()
  File "/home/server/pi/homes/sdeszoek/.julia/conda/3/lib/python3.7/site-packages/matplotlib/__init__.py", line 142, in _check_versions
    from . import ft2font

Stacktrace:
 [1] pyimport(name::String)
   @ PyCall ~/.julia/packages/PyCall/BD546/src/PyCall.jl:550
 [2] pyimport_conda(modulename::String, condapkg::String, channel::String)
   @ PyCall ~/.julia/packages/PyCall/BD546/src/PyCall.jl:708
 [3] pyimport_conda
   @ ~/.julia/packages/PyCall/BD546/src/PyCall.jl:707 [inlined]
 [4] __init__()
   @ PyPlot ~/.julia/packages/PyPlot/XaELc/src/init.jl:185

julia> versioninfo()
Julia Version 1.6.3
Commit ae8452a9e0 (2021-09-23 17:34 UTC)
Platform Info:
  OS: Linux (x86_64-redhat-linux)
  CPU: AMD Opteron(tm) Processor 6172
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, amdfam10)

julia> 
bash-4.2$ ls -l /lib64/libz.so.1
lrwxrwxrwx 1 root root 13 Feb 26  2021 /lib64/libz.so.1 -> libz.so.1.2.7

EDIT:
Thanks to #BeastyBlacksmith
https://github.com/JuliaPlots/Plots.jl/issues/3890#issuecomment-947860489
The solution is that PyPlot and Plots work with the official julialang.org julia linux x64 binary.

It successfully re-precompiles PyPlot previously installed into ~/.julia by the Copr julia package manager.

Plots dependencies needed to be rebuilt.
]build with the official julia binary seems to fix it.

stevengj mentioned this issue Nov 5, 2015

Using pyplot fails with latest anaconda #180

Closed

stevengj mentioned this issue Jun 29, 2016

import PyPlot from automated miniconda produces warning+error due to libpng16.so.16 #229

Closed

stevengj changed the title ~~yet another "using PyPlot" error~~ error loading ZLIB (wrong libz library being linked) Jun 29, 2016

stevengj mentioned this issue Mar 6, 2017

Plots.jl on Clusters JuliaPlots/Plots.jl#519

Closed

johanneslotz added a commit to johanneslotz/DeformableRegistration.jl that referenced this issue Oct 6, 2017

removing all plotting from automated tests

918759a

this circumvents PyPlot issue 151, see JuliaPy/PyPlot.jl#151

stevengj mentioned this issue Oct 17, 2017

Current (v2.3.2) PyPlot fails installation with private miniconda Python #317

Closed

floswald mentioned this issue Oct 30, 2017

libmkl_intel_thread.so : undefined symbol: omp_get_num_procs #329

Closed

This was referenced Nov 28, 2017

using PyPlot -> generates an error now with julia 0.6.0 and 0.6.1 #328

Closed

using PyPlot fails #332

Closed

bblankrot referenced this issue in bblankrot/ParticleScattering.jl Apr 6, 2018

changing pygui backend to tk before using PyPlot

6805e9d

per last comment in [https://github.com/JuliaPy/PyPlot.jl/issues/151](https://github.com/JuliaPy/PyPlot.jl/issues/151)

bblankrot mentioned this issue Apr 6, 2018

changing pygui backend to tk before using PyPlot bblankrot/ParticleScattering.jl#16

Merged

stevengj mentioned this issue Apr 11, 2018

using PyPlot fails under wsl #352

Closed

emcangi mentioned this issue Apr 24, 2018

linux installation without root? JuliaIO/HDF5.jl#97

Closed

stevengj mentioned this issue Apr 24, 2018

Remove indirect dependency on system ZLIB JuliaLang/julia#26888

Merged

stevengj mentioned this issue May 8, 2018

PyPlot unable to import correct version of matplotlib despite correct path being called by PyCall #357

Closed

bgodard mentioned this issue May 19, 2018

ReadOnlyMemoryError when trying to plot over SSH+X #291

Closed

This was referenced May 28, 2018

Crash at "from diffeqpy import de". SciML/diffeqpy#27

Closed

System crash when using pyjulia. JuliaPy/pyjulia#164

Open

stevengj closed this as completed Jun 13, 2018

stevengj mentioned this issue Jun 13, 2018

"/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found JuliaPy/Conda.jl#105

Open

v-i-s-h mentioned this issue Jun 15, 2018

Wrong ZLIB being linked, Affects importing other packages JuliaIO/HDF5.jl#485

Closed

Bam92 mentioned this issue Nov 28, 2018

Missing (up-to-date) dependencies on debian 9.5 (stable) kiwix/kiwix-desktop#40

Closed

calvinp0 mentioned this issue Jan 7, 2023

Solution to RMS Compile Error ReactionMechanismGenerator/T3#95

Merged

error loading ZLIB (wrong libz library being linked) #151

error loading ZLIB (wrong libz library being linked) #151

Comments

bjarthur commented Jul 31, 2015

stevengj commented Jul 31, 2015

bjarthur commented Jul 31, 2015

stevengj commented Jul 31, 2015

stevengj commented Sep 24, 2015

longqian95 commented Oct 15, 2015

stevengj commented Oct 15, 2015

longqian95 commented Oct 30, 2015

stevengj commented Jun 29, 2016 • edited Loading

Luthaf commented Jun 29, 2016

stevengj commented Jun 29, 2016

Luthaf commented Jun 29, 2016

stevengj commented Mar 16, 2017

RalphAS commented Mar 17, 2017

stevengj commented Mar 17, 2017

axsk commented Oct 11, 2017 • edited Loading

CorySimon commented Nov 8, 2017

stevengj commented Nov 8, 2017

zekeriyasari commented Nov 21, 2017 • edited Loading

BoundaryValueProblems commented Nov 28, 2017

stevengj commented Nov 29, 2017

stevengj commented Nov 29, 2017

v-i-s-h commented Mar 23, 2018 • edited Loading

EDIT

urlicht commented May 24, 2018

emcangi commented May 30, 2018

urlicht commented May 30, 2018 • edited Loading

emcangi commented May 30, 2018

stevengj commented Jun 12, 2018

pierre-haessig commented Jun 13, 2018

mzaffalon commented Jun 13, 2018

stevengj commented Jun 13, 2018

oxinabox commented Jun 18, 2018

stevengj commented Jun 18, 2018

emcangi commented Jun 19, 2018

stevengj commented Jun 19, 2018

emcangi commented Jun 19, 2018

emcangi commented Jun 19, 2018 • edited Loading

deszoeke commented Oct 19, 2021 • edited Loading

stevengj commented Jun 29, 2016 •

edited

Loading

axsk commented Oct 11, 2017 •

edited

Loading

zekeriyasari commented Nov 21, 2017 •

edited

Loading

v-i-s-h commented Mar 23, 2018 •

edited

Loading

urlicht commented May 30, 2018 •

edited

Loading

emcangi commented Jun 19, 2018 •

edited

Loading

deszoeke commented Oct 19, 2021 •

edited

Loading