Warning: Use of undefined constant headerfavicons - assumed 'headerfavicons' (this will throw an Error in a future version of PHP) in /home/thetoryp/www/www/wp-content/plugins/easy-favicon/easy-favicon.php on line 6231

Warning: Use of undefined constant headerfavicons - assumed 'headerfavicons' (this will throw an Error in a future version of PHP) in /home/thetoryp/www/www/wp-content/plugins/easy-favicon/easy-favicon.php on line 6279

Warning: Use of undefined constant headerfavicons - assumed 'headerfavicons' (this will throw an Error in a future version of PHP) in /home/thetoryp/www/www/wp-content/plugins/easy-favicon/easy-favicon.php on line 6327
PIL on Snow Leopard: _jpeg_resync_to_restart error - Programming - The Tory Party Skip to content

PIL on Snow Leopard: _jpeg_resync_to_restart error

PIL on Snow Leopard: _jpeg_resync_to_restart error published on 7 Comments on PIL on Snow Leopard: _jpeg_resync_to_restart error

Oh man I just got this working so I’m gonna write it all down in case I have to do this again later.



– jpeg-7
– PyQt 4.6
– PIL (aka Imaging) 1.1.6
– reportlab 2.3
– Snow Leopard (Mac OS X 10.6.4)

I use PIL and reportlab so my PyQt applications can make PDFs and print nicely. Rad. I like reportlab and it does what I need. I really like PyQt 4.6 especially now that Pixmaps have native jpeg support so I don’t need to do a song and dance to show a jpeg in my applications.

But in upgrading to Snow Leopard something in my PIL installation got a little borked. Executing this code:

imageFilePath = somePathToAJpeg
pixmapImage = QtGui.QPixmap(imageFilePath)

#Because it's a bum format, force it with PIL
pilImage = Image.open(imageFilePath)
stringIO = StringIO.StringIO()

pilImage.save(stringIO, format='png')
pixmapImage = QtGui.QPixmap()

Got this error:

Traceback (most recent call last):
File "test/ui/AssetPrinterTest.py", line 89, in testCreatePDF
pdfCreatorObj.createPDF(desiredFilePath, True)
File "/homes/tory/workspace/spLib/ui/AssetPrinter.py", line 183, in createPDF
File "/Library/Python/2.6/site-packages/reportlab/platypus/doctemplate.py", line 1010, in build
BaseDocTemplate.build(self,flowables, canvasmaker=canvasmaker)
File "/Library/Python/2.6/site-packages/PIL/Image.py", line 532, in tostring
File "/Library/Python/2.6/site-packages/PIL/ImageFile.py", line 164, in load
File "/Library/Python/2.6/site-packages/PIL/PngImagePlugin.py", line 381, in load_prepare
File "/Library/Python/2.6/site-packages/PIL/ImageFile.py", line 231, in load_prepare
self.im = Image.core.new(self.mode, self.size)
File "/Library/Python/2.6/site-packages/PIL/Image.py", line 37, in __getattr__
raise ImportError("The _imaging C module is not installed")
ImportError: The _imaging C module is not installed

PyQt 4.6’s native jpeg support meant I could just rip out this code (that I had needed way back in 4.4.3) and my jpegs loaded fine and I could deal with my PIL malfunctions another day.

Today is the day I have to deal with my PIL malfunctions.


There’s a problem with my _imaging C library, you say? Let’s find out some more about it.

Public Image Lame-ited

Stop. Google time.

Google this error, there are many links and many suggestions. I searched and searched for the “click your heels three times” option, but apparently I was going to need to clean house and reinstall.

The good news is it hella worked. Some of my steps might not be strictly necessary, but here’s what I did that worked:


1) Force the gcc and gcov paths to 4.2:

sudo rm /usr/bin/gcc
sudo ln -s /usr/bin/gcc-4.2 /usr/bin/gcc
sudo rm /usr/bin/gcov
sudo ln -s /usr/bin/gcov-4.2 /usr/bin/gcov

(Suggested by Remi in comments here.)

gcc 4.2 is the latest at the time of this writing. gcc 4.0 is required for successful MySQLdb installation, and that’s probably what got borked.

[Also, per Bram Braakman’s advice, I checked my .profile file. (Turns out I didn’t have the explicit “export CC” line he warned about in my .profile file, but I may have the last time I was messing with my PIL install.)]

Now I know I’m using the right version of gcc.


2) In my .profile, commented out these lines I had kicking around:

#ARCHFLAGS="-arch x86_64"

Did I need to do this? I dunno.


3) Picked through my system to delete EVERYTHING called anything like “libjpeg,” “PIL” or “Imaging.”

Over time I’d tried so many different ways to fix this install that I had libjpeg and PIL files everywhere from /usr/local to /opt/local to /sw/lib. It looks like my PIL was only ever referencing the installation at /Library/Python/2.6/site-packages, which is good, but better safe than re-installing.


4) Followed these installation instructions, starting with downloading libjpeg afresh.




YESSSSSSS. Now my PDFs have images!

In our cube we have a gong so that those who have accomplished coding tasks may celebrate their fleeting victories.

I hella gonged the gong out of that gong.

(897 visits, 1 today)


Thank you for showing that it can be done and for the crucial clue that the problem is with libjpegs.

I think I tracked down exactly what caused this. The default libjpeg for some package managers (like fink) in 6b-19, available from libjpeg.sourceforge.net. The latest-greatest that actually works with PIL _imaging is version 9, obtained from http://www.ijg.org/, which is a different distribution from the one available on sourceforge.

Both distributions seem to be available by fink, only the user must specify the package “libjpeg9”. I built libjpeg v9 myself (without a package manager) and it worked fine.

Primary Sidebar