We're back after a server migration that caused effbot.org to fall over a bit harder than expected. Expect some glitches.

Errata for Python Imaging Library 1.1.4

On this page:
Problems building the _imagingft extension
“NameError: global name ‘x’ is not defined”
“NameError: name ‘EXTRA_COMPILE_ARGS’ is not defined”

Problems building the _imagingft extension (@PIL172)

PIL may not build cleanly with recent versions of the freetype2 library (version 2.1 and later). This usually results in a message similar to this one:

building '_imagingft' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -IlibImaging -I/usr/include/freetype2 -I/usr/local/include/python2.3
-c _imagingft.c -o build/temp.linux-i686-2.3/_imagingft.o
In file included from _imagingft.c:20:
/usr/include/freetype2/freetype/freetype.h:20:2:
  #error "`ft2build.h' hasn't been included yet!"
/usr/include/freetype2/freetype/freetype.h:21:2:
  #error "Please always use macros to include FreeType header files."
/usr/include/freetype2/freetype/freetype.h:22:2:
  #error "Example:"
/usr/include/freetype2/freetype/freetype.h:23:2:
  #error "  #include <ft2build.h>"
/usr/include/freetype2/freetype/freetype.h:24:2:
  #error "  #include FT_FREETYPE_H"
error: command 'gcc' failed with exit status 1

To work around this, you have to edit the _imagingft.c file. Change the file as shown by this patch:

--- _imagingft.c
+++ _imagingft.c
@@ -17,7 +17,8 @@
 #include "Python.h"
 #include "Imaging.h"

-#include <freetype/freetype.h>
+#include <ft2build.h>
+#include FT_FREETYPE_H

 #if defined(PY_VERSION_HEX) && PY_VERSION_HEX < 0x01060000
 #define PyObject_DEL(op) PyMem_DEL((op))
(this has been fixed in 1.1.5. the new build process automatically identifies freetype 2.0 and 2.1, and uses the correct include files for the available version)

“NameError: global name ‘x’ is not defined” (@PIL132)

The OleFileIO module contains a typo that tends to reveal itself in odd occasions (usually when trying to open something that looks like, but isn’t, a FlashPix image). Here’s a fix:
Index: OleFileIO.py
===================================================================
--- OleFileIO.py        (revision 214)
+++ OleFileIO.py        (revision 261)
@@ -295,7 +296,7 @@
         fat = []
         for i in range(0, len(sect), 4):
             ix = i32(sect, i)
-            if ix == 0xFFFFFFFEL or x == 0xFFFFFFFFL:
+            if ix == 0xFFFFFFFEL or ix == 0xFFFFFFFFL:
                 break
             s = self.getsect(ix)
             fat = fat + map(lambda i, s=s: i32(s, i), range(0, len(s), 4))
(this has been fixed in 1.1.5)

“NameError: name ‘EXTRA_COMPILE_ARGS’ is not defined” (@PIL124)

Thanks to some last-minute OS X modifications to the setup.py file, you may get NameError exceptions when building PIL.

Traceback (most recent call last):
  File "setup.py", line 287, in ?
    extra_compile_args=EXTRA_COMPILE_ARGS,
NameError: name 'EXTRA_COMPILE_ARGS' is not defined

If you get this error, the following patch should do the trick:

*** Imaging-1.1.4/setup.py Fri May  9 14:00:56 2003
--- Imaging-1.1.4-osx/setup.py Wed Jul 30 14:44:15 2003
***************
*** 216,222 ****
                  ["_imagingtk.c", "Tk/tkImaging.c"],
                  include_dirs=INCLUDE_DIRS,
                  library_dirs=LIBRARY_DIRS,
!                 libraries=LIBRARIES
                  )
              )

--- 216,224 ----
                  ["_imagingtk.c", "Tk/tkImaging.c"],
                  include_dirs=INCLUDE_DIRS,
                  library_dirs=LIBRARY_DIRS,
!                 libraries=LIBRARIES,
!                 extra_compile_args=EXTRA_COMPILE_ARGS,
!                 extra_link_args=EXTRA_LINK_ARGS
                  )
              )

***************
*** 284,291 ****
                  include_dirs=INCLUDE_DIRS,
                  library_dirs=LIBRARY_DIRS,
                  libraries=LIBRARIES,
-                 extra_compile_args=EXTRA_COMPILE_ARGS,
-                 extra_link_args=EXTRA_LINK_ARGS
                  )
              )

--- 286,291 ----
(this is fixed in 1.1.5, of course. no need to report it again.)