Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><code>byp</code> is your virtualenv? I just did the same thing, though with the system Python 2.6 and had no problems. You can install <code>libjpeg</code> directly into the virtualenv if you want, then you won't have to hack the PIL build script. Here's what I did:</p> <pre><code>% mkvirtualenv foo (foo)% cdvirtualenv (foo)% lftpget http://www.ijg.org/files/jpegsrc.v8c.tar.gz (foo)% tar zxf jpegsrc.v8c.tar.gz (foo)% cd jpeg-8c (foo)% CC="gcc -arch x86_64" ./configure --prefix=$VIRTUAL_ENV (foo)% make install (foo)% cd .. (foo)% pip install PIL (foo)% python Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. &gt;&gt;&gt; import _imaging &gt;&gt;&gt; _imaging &lt;module '_imaging' from '/Users/nicholas/LMI/foo/lib/python2.6/site-packages/PIL/_imaging.so'&gt; &gt;&gt;&gt; ^D </code></pre> <p>While <code>_imaging.so</code> got built for <code>i386</code>, <code>ppc</code> and <code>x86_64</code> (because that is how Apple's Python was compiled), <code>libjpeg</code> was compiled for <code>x86_64</code> only because of the flags I gave gcc:</p> <pre><code>(foo)% file lib/libjpeg.8.dylib lib/libjpeg.8.dylib: Mach-O 64-bit dynamically linked shared library x86_64 (foo)% file lib/python2.6/site-packages/PIL/_imaging.so lib/python2.6/site-packages/PIL/_imaging.so: Mach-O universal binary with 3 architectures lib/python2.6/site-packages/PIL/_imaging.so (for architecture i386): Mach-O bundle i386 lib/python2.6/site-packages/PIL/_imaging.so (for architecture ppc7400): Mach-O bundle ppc lib/python2.6/site-packages/PIL/_imaging.so (for architecture x86_64): Mach-O 64-bit bundle x86_64 (foo)% otool -L lib/python2.6/site-packages/PIL/_imaging.so lib/python2.6/site-packages/PIL/_imaging.so: /Users/nicholas/LMI/foo/lib/libjpeg.8.dylib (compatibility version 12.0.0, current version 12.0.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1) </code></pre> <p>Because <code>_imaging.so</code> links to <code>libjpeg</code> dynamically, it fails at load time if a dylib is not available with the expected architecture. I was able to provoke something similar to what you saw by running Python as 32-bit:</p> <pre><code>(foo)% arch -i386 python Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. &gt;&gt;&gt; import _imaging Traceback (most recent call last): File "&lt;stdin&gt;", line 1, in &lt;module&gt; ImportError: dlopen(/Users/nicholas/LMI/foo/lib/python2.6/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart Referenced from: /Users/nicholas/LMI/foo/lib/python2.6/site-packages/PIL/_imaging.so Expected in: flat namespace in /Users/nicholas/LMI/foo/lib/python2.6/site-packages/PIL/_imaging.so </code></pre> <p>So I'd check that the architectures of Python, PIL and libjpeg are compatible. It's rather annoying you don't get a better error message though!</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload