Develop Reference

pyenv building python on Linux Mint with WARNING: renaming "_ctypes"

For some reason, pyenv is failing to install any versions of python due to an issue with libffi. I have all the libraries installed, yet I get:
*** WARNING: renaming "_ctypes" since importing it failed: libffi.so.8: cannot open shared object file: No such file or directory
The curious thing is libffi is installed, but it's a different version:
❯ find /usr -name '*ffi.so*'
/usr/lib/x86_64-linux-gnu/libffi.so
/usr/lib/x86_64-linux-gnu/libffi.so.7
/usr/lib/x86_64-linux-gnu/libffi.so.7.1.0
So, the build is trying libffi.so.8 even though libffi.so.7 is installed.
Can anybody explain how debian-based systems choose the version of the shared library? I've checked the .h and .pc files, but nothing jumps out at me showing why it would be referencing version 8.
❯ ldconfig -p | grep libffi.so
libffi.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libffi.so.7
libffi.so.7 (libc6) => /lib/i386-linux-gnu/libffi.so.7
libffi.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libffi.so
Additional note: I notice libffi is also installed by homebrew. However, it's the same version as Mint has installed, so it's not a conflict (as far as I can tell).
Any suggestions?
❯ uname -a
Linux mcrowe-XPS-15-9560 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
❯ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=20.2
DISTRIB_CODENAME=uma
DISTRIB_DESCRIPTION="Linux Mint 20.2 Uma"

FWIW, I am seeing a similar issue. When I installed 3.9.7 with pyenv, it found libffi correctly. Today, when I install 3.9.9 I get the same error as you.
*** WARNING: renaming "_ctypes" since importing it failed: libffi.so.8: cannot open shared object file: No such file or directory
The symptom that got me looking into this was an attempt to pip install blinker which gave me an error about missing _ctypes, which was odd since 3.9.7 had no issues.
ModuleNotFoundError: No module named '_ctypes'
In my case brew had updated to libffi 3.4 vs the 3.3 that Ubuntu 20.04 is using. I figure there must be some misordering of paths where it finds the brew headers to compile, but cannot find the brew .so to link.
I would like to learn to sort that out, but in the meantime, I did the following, answering y to the pyenv prompt to reinstall over existing 3.9.9
$ brew remove --ignore-dependencies libffi
$ pyenv install 3.9.9
$ brew install libffi
That was enough of a workaround to let me return to what I wanted to deal with.

Pillow recognizes JPEG encoder on install, but not use

I'm doing some work on a vagrant box running Ubuntu 13.04 and python 3.3. I've installed Pillow and libjpeg-dev (installing the latter first, as recommended), and when I install (or re-install Pillow, I see this:
--------------------------------------------------------------------
PIL SETUP SUMMARY
--------------------------------------------------------------------
version Pillow 2.3.0
platform linux 3.3.1 (default, Sep 25 2013, 19:29:01)
[GCC 4.7.3]
--------------------------------------------------------------------
*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
Great! JPEG encoder recognized. Except, when I run Pillow's selftest.py script, it fails a bunch of tests and starts off with this:
--------------------------------------------------------------------
Pillow 2.3.0 TEST SUMMARY
--------------------------------------------------------------------
Python modules loaded from /usr/local/lib/python3.3/dist-packages/PIL
Binary modules loaded from /usr/local/lib/python3.3/dist-packages/PIL
--------------------------------------------------------------------
--- PIL CORE support ok
*** TKINTER support not installed
*** JPEG support not installed
--- ZLIB (PNG/ZIP) support ok
So now it's not recognizing the JPEG decoder. To make sure this isn't just a problem with selftest.py, I did my testing and sure enough I can make and manipulate .pngs but not .jpgs. I've searched around and tried some suggested solutions, including making a symbolic link to the jpg library, like so:
sudo ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib
No dice. Anybody have an idea of something else I could try to get the jpeg decoder working? It really isn't practical for me to restrict the workflow entirely to .png.

And, this is why I need to wait 24 hours before posting questions. I needed to pay attention to the Pillow install path. It works if I create the symlink like so:
sudo ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/local/lib/
/usr/lib wasn't in the Pillow search path, but the above is.

PIL / Easy Thumbnails Missing Dependencies Django

I ported a web application to another machine, but am having a problem getting django easy thumbnails setup on another team member's machine (mac osx 10.6 snow leopard). I know it requires PIL, but am having problems getting it and perhaps its dependencies set up on the machine.
I read this post detailing how to install libjpeg on a mac, but still did not have luck. Afterwards, I tried to uninstall PIL and instead use Pillow, but still does not work:
(newenv)wsp049614wss:site-packages Admin$ pip uninstall pil
Successfully uninstalled PIL
(newenv)wsp049614wss:site-packages Admin$ pip install pillow
Downloading/unpacking pillow
Downloading Pillow-2.2.1.zip (2.2MB): 2.2MB downloaded
Running setup.py egg_info for package pillow
--------------------------------------------------------------------
PIL SETUP SUMMARY
--------------------------------------------------------------------
version Pillow 2.2.1
platform darwin 2.7.5 (default, Oct 27 2013, 12:25:46)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
*** TIFF G3/G4 (experimental) support not available
--- FREETYPE2 support available
*** LITTLECMS support not available
*** WEBP support not available
*** WEBPMUX support not available
--------------------------------------------------------------------
What am I missing? How can I get easy_thumbnails to work? I did not change anything in the codebase, and easy-thumbnails works on other machines. Thanks for any ideas!

Oh no - you have the dreaded libjpeg Snow leopard issue. Basically your standard pip install of PIL doesn't work, it messes up the libjpeg C lib. There are a million blogs on this issue, this one worked for me, but you'll have to hunt around trying out various fixes.

PNG display in PIL broken on OS X Mavericks?

I've noticed that PNG images aren't displaying in Tkinter apps using ImageTk.PhotoImage in OS X Mavericks. But, GIFs and JPEGs display fine. There's no error printed or exception thrown and debugging the code shows the image is read and has the correct height & width. Here's a simplified example:
import Tkinter
from PIL import Image, ImageTk
logo_file = 'test.png'
#logo_file = 'test.gif'
class Application(Tkinter.Frame):
def __init__(self, master):
Tkinter.Frame.__init__(self, master)
self.master.minsize(width=512, height=256)
self.master.config()
self.pack()
self.main_frame = Tkinter.Frame()
self.some_image = ImageTk.PhotoImage(Image.open(logo_file))
some_label = Tkinter.Label(self.main_frame, image=self.some_image)
some_label.config()
some_label.pack(side='top')
self.main_frame.place(in_=self.master, anchor='c', relx=.5, rely=.5)
root = Tkinter.Tk()
app = Application(root)
app.mainloop()
If you use a GIF the image will be displayed, but using a PNG it will not. Again, this is only happening on OS X Mavericks, Mountain Lion works fine. I've tried re-installing (compiling PIL) with no luck, as well as trying a new virtualenv.
Is there perhaps some PNG attribute I need to set correctly when creating/saving the PNG? Or is this a bug in PIL or Tkinter or OS X?
Update to add some details
I'm using:
Python 2.7.5 (/usr/bin/python)
PIL 1.1.7 (compiled using pip)
This is on a machine that was just updated to Mavericks from Mountain Lion, and previously had PIL installed, and I haven't messed with the system Python shipped by Apple.
Update 2 Pillow setup summary
I installed Pillow 2.2.1 and it says it has PNG support:
--------------------------------------------------------------------
PIL SETUP SUMMARY
--------------------------------------------------------------------
version Pillow 2.2.1
platform darwin 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- TIFF G3/G4 (experimental) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
*** WEBP support not available
*** WEBPMUX support not available
--------------------------------------------------------------------
I also uninstalled and re-installed libpng using brew (libpng 1.5.14). I then re-installed Pillow to make sure it built with it, though I think it uses zlib.
Update 3 trying to build Python 2.7.5
Perhaps the issue is with zlib, trying to compile Python 2.7.5 I get this:
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _sqlite3 _ssl
bsddb185 dbm dl
gdbm imageop linuxaudiodev
nis ossaudiodev readline
spwd sunaudiodev zlib
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Failed to build these modules:
_tkinter

I think your problem is that your PIL was built without PNG support, or with only partial PNG support, on your Mavericks machine.
If PIL can't find both libpng and libz where it wants to, you won't have complete PNG support. And after upgrading from Mountain Lion to Mavericks, this seems to sometimes be a problem.
This may not be the same problem you're having. For example, it could be down to Apple using a buggy version of Tcl/Tk again (as they infamously did in Snow Leopard). But it's definitely worth trying.
With Pillow, and some versions of old-school PIL (but really, if you're not using Pillow, you almost definitely should be), the end of the install process gives you a friendly "PIL SETUP SUMMARY" section that shows you all the important configuration stuff.
I had the exact same problem with Pillow 2.2.1 on a locally-built Python 3.3.2. I solved it by using Homebrew to install libpng, then rebuilding Pillow:
$ brew install libpng
$ pip-3.3 uninstall pillow
$ pip-3.3 install pillow

I was experiencing the same problem and I did the following. It seems to be fixed.
sudo unistall pillow
xcode-select --install
pip install pillow
It seems to be working great. I also installed all the items below, but it seems you have it already installed
brew install libtiff libjpeg libpng webp littlecms

Did you install Pillow dependencies?
pip uninstall Pillow
brew install libtiff libjpeg webp littlecms
pip install Pillow
You will need HomeBrew to execute the brew command.

I installed Pillow from homebrew (brew install Pillow), all necessary dependencies will be installed automatically. Problem solved.

_imaging C module error in python PIL

I have read the other posts about the notorious _imaging C module error when installing PIL on Mac OS X and none of the solutions provided anywhere, including the PIL FAQ, have proven helpful.
I have the newest versions of libjpeg and zlib freshly installed from source. I have edited the Makefiles in each of these to include the option -arch i386 in the LD_FLAGS variable for 32-bit builds. PIL installs with no problems of any kind and the install summary printed to the terminal says that JPEG, TIFF, and PNG support are all OK. After that I try the self test:
new-host:Imaging-1.1.7 ely$ python selftest.py
*** The _imaging C module is not installed
This is commonly seen for a variety of reasons. Probing deeper, here I try to import _imaging directly in python.
new-host:Imaging-1.1.7 ely$ python
ActivePython 2.7.1.4 (ActiveState Software Inc.) based on
Python 2.7.1 (r271:86832, Feb 7 2011, 11:33:10)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import PIL
>>> import _imaging
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/_imaging.so
Expected in: dynamic lookup
Here again, the 'Symbol not found: _jpeg_resync_to_restart' is notorious and common, and many people have suggested this has to do with incorrect path to libjpeg. I've checked again and again and I only have libjpeg (as well as zlib, etc.) installed in my home directory, all in separate folders, from source, and all of this is marked correctly in the file setup.py.
So, PIL should be getting its jpeg support (and zlib, etc.) from the right places. All the dependencies are installed. I can see _imaging.so in my sys.path, yet I still get this _jpeg_resync_to_restart error.
Are there any ideas that don't link to alternate posts? I have spent ~7 hours reading and trying possible solutions from posts in every forum I can find.

Since you have been trying this a few times, I recommend running a few commands to clean out the old items first and start from the beginning.
I used jpeg v8c and Imaging 1.1.6 on Mac OS X, 10.6 and 10.7
get v8c of jpeg
cd into jpeg directory.
sudo make clean
CC="gcc -arch i386" ./configure --enable-shared --enable-static
make
sudo make install
get imaging i am using 1.1.6
untar
cd into imaging
sudo rm -rf build
vi setup.py
JPEG_ROOT = libinclude(“/usr/local/lib”)
sudo python setup.py install
And it’s that simple
Run your python interpreter,
import PIL
import _imaging
import Image
if all is well, then your all set.
Here is the full article on my blog Python 2.7, OSX Lion, PIL and Imaging

I have faced the same problem this evening on my mac running Mac OS X v10.7.5, Python v2.7.1 with PIL Imaging 1.1.7 and jpeg 8d.
Summarizing - the key to success in my case was:
export ARCHFLAGS="-arch x86_64"
Nothing from the other answers have solved the issue, constantly I've been getting:
The _imaging C module is not installed caused by:
Symbol not found: _jpeg_resync_to_restart.
Digging here and there finally I've found the solution, at least works for me:
ensure you don't have any obvious libjpeg libs on the system: find / -iname "libjpe*" will tell you that. I have temporarily changed places where they exist so no one could find them (especially /sw was interacting with PIL in my case):
mv opt opt-OFF
mv sw sw-OFF
These locations have been created by mac ports and fink - be warned that it is quite possible that FREETYPE2 might not be found by PIL after this move - if you need it, then just rename libjpeg parts in those locations.
in PIL Imaging src directory edit setup.py as described above to set JPEG_ROOT to /usr/local, try to run:
rm -rf build ; python setup.py build 2> /tmp/err > /tmp/log
Check in /tmp/log - you should not see JPEG support available. You can now go to the next step.
go to jpeg-8d src directory and run:
export ARCHFLAGS="-arch x86_64"
sudo make clean; CC="gcc -arch x86_64" ./configure --enable-shared --enable-static
sudo make install
go back to PIL Imaging, run these commands:
export ARCHFLAGS="-arch x86_64"
sudo rm -rf build ; python setup.py build 2> /tmp/err > /tmp/log
Check in /tmp/log - you should now see "JPEG support available", check /tmp/err - search for "jpeg" - if you see something like this:
ld: warning: ignoring file /usr/local/lib/libjpeg.dylib, file was built for unsupported file format which is not the architecture being linked (i386) - then the arch flags (both set by ARCHFLAGS and -arch) failed to trigger - investigate that case, it is crucial. If you don't see this, then you're lucky and you can invoke the installation:
export ARCHFLAGS="-arch x86_64"
sudo rm -rf build ; sudo python setup.py install
Check if your PIL works:
python selftest.py
or
echo "import _imaging" | python && echo "Works"
I hope this helps.

The problem is that the _imaging module is linked to libjpeg dynamically, not statically. The libjpeg code is not included in the _imaging module directly. This means that your platform's dynamic linker has to be able to find libjpeg in order to load and link it. My MacOS knowledge here is fuzzy, but as I recall its dynamic linker is called dyld, and its manpage may provide more information on the options you have.
Normally, the platform's dynamic linker won't be looking in your homedirectory for libraries -- but you can tell it to, for example by setting the DYLD_LIBRARY_PATH environment variable, or editing the system-wide configuration (if there is one.) Setting that environment variable usually has to be done before you start Python, though, so it may not be suitable. You may want to try to embed the runtime search path into the _imaging extension module, which is usually done by passing -rpath to the linker -- but I don't know if MacOS's linker offers that capability. Finally, you can just build libjpeg as a static library, instead of a shared one, and have the _imaging module link against that. That would avoid the whole shared library situation for libjpeg. For libjpeg, this is probably done by running its configure script with --enable-static --disable-shared.

I tried many most all of these suggestions (as well as two other suggestions on referenced blogs) on an old 10.6 Mac install. None of them worked as-is, however, reading behind the lines I was able to fix my problem. I added to the PIL setup.py in find_include_file() right before the return 1 line "print os.path.join(directory, include)". This allowed me to track down which libjpeg PIL is building against. Then I would build PIL, find the libjpeg it referenced (various copies in /sw, /opt/, /usr/local/lib, ...), and delete that libjpeg (both header and lib files).
Finally with a clean system I built and installed libjpeg source tarball that I'd downloaded myself, followed by building and installing PIL from source. This worked. As a fallback you could always disable libjpeg by removing the above files as described or else always returning zero from the described above function in setup.py.

Works well for me on Mountain Lion 10.8.2:
Step One. Removing all jpeg packages. For MacPorts:
sudo port -f uninstall jpeg or sudo port -f uninstall jpeg #version_here
We need to remove all jpeg versions!
Step Two. Remove PIL: pip uninstall PIL
Step Three. Install jpeg package again. For MacPorts: sudo port install jpeg
Step Four. Install PIL again: pip install PIL
>>> import PIL
>>> import _imaging
No errors!
How to remove ALL jpeg packages?
$ port installed | grep -i jpeg
jpeg #8c_0
jpeg #9a_0 (active)
$ sudo port -f uninstall jpeg #8c_0
$ sudo port -f uninstall jpeg #9a_0
Don't care about dependies. Beacause we need to install jpeg package again:
$ sudo port install jpeg

I ran into all the errors you guys have mentioned. I broke down and just used virtualenv and installed Pillow instead. it worked:
sudo pip install virtualenv
virtualenv python_script && cd !$
. /activate/bin
pip install Pillow

I had the same problem, with Python 2.7 and OSX Lion, and basically followed #ApPeL process and re-installed libjpeg and PIL. libjpeg seemed to be installed correctly, and PIL seemed to find it correctly, but running python -v and then import _imaging gave always this error:
ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/_imaging.so,
2): Symbol not found: _jpeg_resync_to_restart
After installing and re-installing libjpeg (version 8d) and PIL (version 1.1.7) twenty times with slightly different options, what did the trick was making sure I removed all libjpeg files under /usr/local/include (headers), as well as the files under /user/local/lib.
I didn't need to install PIL from source, I used pip install pil

This worked for me-
http://www.thetoryparty.com/2010/08/31/pil-on-snow-leopard-_jpeg_resync_to_restart-error/

I have been attempting to install PIL (OS X 10.7.5, Python 2.7.3) for about 5 hours. I too have been bogged down with the 'Symbol not found: _jpeg_resync_to_restart" error and have tried many of the proposed solutions to no avail, including reinstalling all of its dependencies. Finally, I discovered a double-clickable installation of Pillow.
Thank you Rudix! Now "import PIL" and "import _imaging" work!
p.s. I had installed libjpeg via i didn't specifically delete this install, so I'm not sure if this was part of the final solution or not.