PIL - libjpeg.so.8: cannot open shared object file: No such file or directory

Question

Compiled the libjpeg v8, PIL 1.1.7 and and import for _imaging works on the system Python, but spouts this error inside the virtualenv:

libjpeg.so.8: cannot open shared object file: No such file or directory

here is the error run with a python -v interpreter inside the virtualenv

>>> import _imaging
dlopen("/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/PIL/_imaging.so", 2);
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: libjpeg.so.8: cannot open shared object file: No such file or directory

and here are the paths:

/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/distribute-0.6.14-py2.6.egg
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/pip-0.8.1-py2.6.egg
/home/ygamretuta/dev/py/django/lib/python2.6
/home/ygamretuta/dev/py/django/lib/python2.6/plat-linux2
/home/ygamretuta/dev/py/django/lib/python2.6/lib-tk
/home/ygamretuta/dev/py/django/lib/python2.6/lib-old
/home/ygamretuta/dev/py/django/lib/python2.6/lib-dynload
/usr/lib/python2.6
/usr/lib/python2.6/plat-linux2
/usr/lib/python2.6/lib-tk
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages
/home/ygamretuta/dev/py/django/lib/python2.6/site-packages/PIL

I am using Ubuntu 10.10 and this is the uname-a output:

Linux ygam-desktop 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:40:58 UTC 2011 i686 GNU/Linux

I am using Python 2.6

I followed the following guides already:

http://appelfreelance.com/2010/06/libjpeg-pil-snow-leopard-python2-6-_jpeg_resync_to_restart/

http://www.jooncode.com/2010/12/02/python-pil-jpeg-resync-restart-error-imaging-module-solve/

http://djangodays.com/2008/09/03/django-imagefield-validation-error-caused-by-incorrect-pil-installation-on-mac/

Platon

Answer 1

See an explanation here: Why can't Python find shared objects that are in directories in sys.path?

A quick fix is to add the directory that contains libjpeg.so.8 to your /etc/ld.so.conf file, and then run ldconfig

Doubtless

Answer 2

Also if you are doing local Python installations you can also control dynamic linking on the session level using LD_LIBRARY_PATH environment variable::

 export LD_LIBRARY_PATH=/srv/plone/python/python-2.6/lib
 python
 import _imaging
 ...

This way you cannot break your OS itself, even accidentally. (It happens: http://opensourcehacker.com/2011/08/31/zend-server-installation-potentially-kills-your-ssh/)

Kyl

Useful tip, especially when using the python buildout (github.com/collective/buildout.python). – Prodigal

Mark: Please check if collective.buildout.python gives -rpath when compiling libraries. -rpath given to the linker will make binary to prefer that folder when looking for dynamic libraries. Effectively you could set the built python (let's say python2.6) to prefer buildout.python/python-2.6/lib folder always when looking PIL, lxml, etc. and thus fixing this problem once for all. – Kyl

Mikko: I'll look into the -rpath parameter, thanks. For now I've removed the LD_LIBRARY_PATH setting from my .bashrc because it also leads to the following error: "evince: error while loading shared libraries: libz.so.1: failed to map segment from shared object: Permission denied". Adding the path to e.g. /etc/ld.so.conf.d/python.conf also results in the same error. – Prodigal

Sounds like UNIX file permission issue. If you need help with that I suggest you open another question. – Kyl

For the record: on a freshly installed system, I cannot reproduce the problem with the python buildout. So it was probably a problem with a (old) misconfigured machine and not the buildout. – Prodigal

Answer 3

maybe just install libjpeg

conda install -c conda-forge libjpeg-turbo

Frier

Answer 4

Compiling the library from source works too: http://www.ijg.org/files/

Make sure to use jpegsrc.v8.tar.gz if you're on a Unix like system though. jpegsr8.zip appears to be the MS version, and throws all the standard formatting issues while building.

Enthusiast