Matplotlib error: libfreetype.6.dylib

Question

I'm trying to run the following python script (I'm using Vim):

import numpy as np;
import scipy as sp;
from scipy import misc;
import matplotlib.pyplot as plt;
image = misc.imread('test_image.jpg');
np.fliplr(image);
plt.imshow(image);

When I do, I get the following:

Traceback (most recent call last):
  File "test.py", line 4, in <module>
    import matplotlib.pyplot as plt;
  File "/Library/Python/2.7/site-packages/matplotlib/pyplot.py", line 24, in <module>
    import matplotlib.colorbar
  File "/Library/Python/2.7/site-packages/matplotlib/colorbar.py", line 29, in <module>
    import matplotlib.collections as collections
  File "/Library/Python/2.7/site-packages/matplotlib/collections.py", line 23, in <module>
    import matplotlib.backend_bases as backend_bases
  File "/Library/Python/2.7/site-packages/matplotlib/backend_bases.py", line 50, in <module>
    import matplotlib.textpath as textpath
  File "/Library/Python/2.7/site-packages/matplotlib/textpath.py", line 11, in <module>
    import matplotlib.font_manager as font_manager
  File "/Library/Python/2.7/site-packages/matplotlib/font_manager.py", line 53, in <module>
    from matplotlib import ft2font
ImportError: dlopen(/Library/Python/2.7/site-packages/matplotlib/ft2font.so, 2): Library not loaded: @loader_path/../../../libfreetype.6.dylib
  Referenced from: /Library/Python/2.7/site-packages/matplotlib/ft2font.so
  Reason: image not found
shell returned 1

I tried reinstalling brew, reinstalling freetype, matplotlib, and numpy in brew, and I uninstalled MacPorts with no change in the error. Suggestions?

EDIT: After uninstalling MacPorts and then doing another reinstall of brew, I now get this error instead.

Fatal Python error: PyThreadState_Get: no current thread Command terminated

The error only appears when I import matplotlib, so I'm guessing the issue is with matplotlib. I will try to reinstall it with brew.

EDIT2: I've been trying from this page to no avail, but I think my error is probably related to that one.

Answer 1

[MacOS X] Ran into the same problem after installing graphviz (to visualize decision tree). Without carefully isolating environment, this new package appears to have put its own favorite version of freetype into my default python runtime library path. Then when doing a simple import import matplotlib.pyplot as plt, I got error messages:

ImportError: dlopen(/Users/shandou/anaconda3/lib/python3.6/site-
packages/matplotlib/ft2font.cpython-36m-darwin.so, 2): Library not 
loaded: @rpath/libfreetype.6.dylib
Referenced from: /Users/shandou/anaconda3/lib/python3.6/site- 
packages/matplotlib/ft2font.cpython-36m-darwin.so
Reason: Incompatible library version: ft2font.cpython-36m-darwin.so 
requires version 22.0.0 or later, but libfreetype.6.dylib provides 
version 21.0.0

At first, I could not understand what @rpath is really pointing to. Checked with locate libfreetype and it looks like for my default python environment, I have (1) /Users/shandou/anaconda3/lib/libfreetype.6.dylib and (2) /Users/shandou/anaconda3/pkgs/freetype-2.8.1-0

I tried the following two fixes. The first one solved the immediate need of making matplotlib import work, but later caused problems in sphinx auto doc generation. The second one is a cleaner fix that made both work.

---

Fix 1: conda uninstall and then pip install matplotlib

• Context: I use anaconda python distribution and use conda as my main package manager
• Spoiler alert: temporarily fixed import problem, but got me into trouble later when using sphinx
• Takeaway: mixing pip and conda installation for major libraries can be problematic

Following @Robbie Capps's suggestion above, I uninstalled matplotlib originally installed with conda and reinstalled it with pip instead. Afterwards matplotlib import works okay and I was able to continue working until later I ran into errors when running sphinx for documenting codes:

File "/Users/shandou/anaconda3/lib/python3.6/site-
packages/matplotlib/backends/backend_macosx.py", line 17, in <module>
from matplotlib.backends import _macosx
RuntimeError: Python is not installed as a framework. The Mac OS X 
backend will not be able to function correctly if Python is not 
installed as a framework. See the Python documentation for more 
information on installing Python as a framework on Mac OS X. Please 
either reinstall Python as a framework, or try one of the other 
backends. If you are using (Ana)Conda please install python.app and 
replace the use of 'python' with 'pythonw'. See 'Working with 
Matplotlib on OSX' in the Matplotlib FAQ for more information. 

That looks hairy, but if I read this correctly, the gist of the message is: sphinx is not happy about me mixing conda and pip install.

So I ended up reverting matplotlib back to conda installation. Sadly the original libfreetype error immediately returns and I was unable to do basic matplotlib import (darn...)

---

Fix 2: Update freetype library located in runtime path (@rpath in the error message)

• Context: I tried updating freetype, libpng, and matplotlib--basically anything that the web would suggest
• Spoiler alert: If runtime path library is not updated, I am left with the same error message about incompatible libfreetype

[Step 1] Brew install freetype library:

$ brew install freetype
$ brew link --overwrite freetype 

When checking the library version in /usr/local/Cellar/freetype/2.9/lib/, I get output as below:

$ otool -L libfreetype.6.dylib | head -n 2
libfreetype.6.dylib:
/usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 23.0.0, current version 23.0.0)

This is version 21+, so we are one step closer to solve the problem

[Step 2] Copy /usr/local/Cellar/freetype/2.9/lib/libfreetype.6.dylib to python runtime library path

It turns out even after updating freetype library with conda, the runtime library is not updated. The final solution that works for me is to force copy newer freetype lib to the runtime path:

$ cd /Users/shandou/anaconda3/lib/
$ sudo cp /usr/local/Cellar/freetype/2.9/lib/libfreetype.6.dylib .

Only then, the freetype library version incompatibility problem is gone, and both matplotlib import and sphinx are happy

---

Bottom line: Fix 2 is the cleaner way to go.

Answer 2

It sounds like you already (at least partially) answered your own question, but I solved this same error, in a somewhat different fashion. Summary: I used otool and install_name_tool to manually change the linkage from the *.so file to a different *.dylib. I'm posting it here mostly as an illustration of how build systems can quickly turn into rat's nests if you're not careful.

Background

I am using conda to manage the virtual environment for a software project I am trying to compile from source (GNU Radio). In order to build the graphics submodule of this project (gr-qtgui) natively on my Mac, I believe I committed some pretty heinous crimes against nature -- more on this below.

My basic strategy to avoid build problems is to rely on a single package manager as much as possible. In this case, the honor went to conda, though some of it required brew and pip. As I'm writing this, I'm now wondering whether I should have linked against the Mac frameworks for Qt4, but what I ended up doing was linking against libQtCore.dylib et al. installed by conda in ~/miniconda3/envs/gr/lib.*

Graphics issues & Resolution

After getting GNU Radio to compile, I then conda install'd matplotlib in this virtual environment. I was initially getting a similar error as OP originally mentions:

ImportError: dlopen(/Users/strotmc1/miniconda3/envs/gr/lib/python2.7/site-packages/matplotlib/ft2font.so, 2): Library not loaded: @rpath/libfreetype.6.dylib
Referenced from: /Users/strotmc1/miniconda3/envs/gr/lib/python2.7/site-packages/matplotlib/ft2font.so
Reason: Incompatible library version: ft2font.so requires version 21.0.0 or later, but libfreetype.6.dylib provides version 14.0.0

I solved it by navigating to the offending shared object's directory and inspecting it:

>> cd ~/miniconda3/envs/gr/lib/python2.7/site-packages/matplotlib
>> otool -L ft2font.so
  ft2font.so:
    @rpath/libfreetype.6.dylib (compatibility version 21.0.0, current version 21.0.0)
    @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
>> otool -l ft2font.so
    ...
     Load command 9
      cmd LC_LOAD_DYLIB
  cmdsize 56
     name @rpath/libfreetype.6.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 21.0.0
 compatibility version 21.0.0
    ...
    Load command 12
         cmd LC_RPATH
     cmdsize 272
        path /Users/strotmc1/miniconda3/envs/gr/lib (offset 12)
    ...

In other words, it's linking to the libfreetype.dylib located inside the virtual environment, not on the system. Sort of makes sense as an error, because pyplot is also trying to access the graphics libraries, which were already strangely configured. My solution was to switch to linking against the homebrew version of freetype:

>> install_name_tool -change @rpath/libfreetype.6.dylib /usr/local/Cellar/freetype/2.9/lib/libfreetype.6.dylib ft2font.so 

and now matplotlib works!

Moral of the story

I said from the beginning that this story is ugly. After finishing writing this up, I'm left with the following conclusions:

1. Despite being able to compile large software projects, I still don't really know what the hell I'm doing.
2. Given the difficulty of writing general-purpose libraries, and how much variation can exist across platforms, and that all users set up their systems differently, I'm amazed that anything ever works.
3. On the other hand, is this really the best we can do? It seems like complexity is the source of the problem. Does any tool sophisticated enough to manage the complexity necessarily introduce more complexity into the system, and thus more opportunities for failure?

Sorry this turned into more of a musing than an answer -- perhaps someone would be so kind to suggest a better place for this type of rambling answer?

*To be completely frank, I never even considered trying to link against the Qt frameworks located in /Library/Frameworks. I'm not sure if the build tools (here, cmake) are smart enough to find these Frameworks, because I haven't tried. I will consider posing this question to the community.

Answer 3

Fixed it... sort of.

Fixed it.

I uninstalled with brew uninstall matplotlib and then installed with pip install matplotlib. The pip version now works. although I think something is wrong with my code because I don't get an image output.

I uninstalled all of my installations of python and then installed ipython, which worked fine. Also, I was forgetting to add plt.show(); after my imshow(); commands... :-( .... but at least someone else has made this mistake before me ...

Refer to this page for very thorough help with any matplotlib imshow issues:

matplotlib does not show my drawings although I call pyplot.show()

Answer 4

You can try to run python with Anaconda and check the version of freetype in your conda environment.

I got the same type of error when I try to install opencv in conda. And finally it was solved by one command:

conda update freetype

Answer 5

Two steps to solve the problem:

Step 1: Updating freetype and coping the .dylib to the anaconda lib folder:

brew upgrade freetype

cp /usr/local/Cellar/freetype/2.10.4/lib/libfreetype.dylib ~/opt/anaconda3/lib/

Step 2: Following the import sequence as below:

 import matplotlib
 matplotlib.use('PS')
 import matplotlib.pyplot as plt
 

Answer 6

Found one immediate solution that worked for me. Due to multiple projects in same environment, my matplotlib was not supporting new changes.

pip3 uninstall matplotlib
pip3 install matplotlib

Answer 7

Check path tou your image (and doublecheck) This is in your traceback: "Reason: image not found"

Also there is no need to use ';' in python.