[Image-SIG] another libjpeg problem - PIL can't find it at runtime? (long)
john walshaw (JIC)
john.walshaw at bbsrc.ac.uk
Mon Sep 25 20:34:44 CEST 2006
I have a problem with PIL 1.1.5 with Python 2.2.3 on Tru 64. This is
another libjpeg problem, occurring at runtime - there are no complaints
from PIL about libjpeg when I build. I have libjpeg 6b. This appears to
be a different problem to the one posted on 22nd. I can't say I'm too
experienced with Python libs so hopefully I'm just making a very obvious
Doing the PIL build proceeds to completion without errors, eventually
showing "--- JPEG support ok" etc.
But the selftest.py script gives: "*** The _imaging C module is not
It turns out that this is because _imaging.so can't resolve
"jpeg_CreateCompress" (and presumably other jpeg_* routines if it got
that far). E.g. if I do the following in the Imaging-1.1.5 dir:
>>> import sys
>>> import _imaging
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: dlopen: PIL/_imaging.so: symbol "jpeg_CreateCompress"
If I just proceed with the installation anyway (python setup.py
install), then everything seems to get put in the right place, but doing
'import _imaging' then just produces the same problem with the correctly
installed _imaging, i.e.
I have tried building from fresh again with various tweaks, e.g. adding
JPEG_ROOT = "/usr/local/lib", "/usr/local/include"
because that's where the libjpeg.a and jpeglib.h files are, and these
both define jpeg_CreateCompress of course, but still the same problem
occurs after the build.
Attempts at non-fresh rebuilds just give:
skipping '_imaging' extension (up-to-date)
skipping '_imagingft' extension (up-to-date)
Very basic question: how can I be sure where Python is looking for libs
at runtime? Presumably there is something besides sys.path (which I did
fiddle with just in case, but no luck).
Any advice much appreciated. I've found a few descriptions of other
libjpeg problems with PIL but am stumped with this.
More information about the Image-SIG