PIL and Snow Leopard

[Jerry LeVan]

From: Jerry LeVan <Jerry.Levan@...>

Date: October 3, 2009 6:32:45 PM EDT

To: Bill Janssen <janssen@...>

Cc: "pythonmac-sig@..." <pythonmac-sig@...>

Subject: Re: [Pythonmac-SIG] PIL and Snow Leopard

On Oct 2, 2009, at 7:40 PM, Bill Janssen wrote:

Jerry LeVan <jerry.levan@...> wrote:

Is building PIL on Snow Leopard 'easy' I have the apple python  

(32/64)

installed and the python.org 2.6.2 (32 bit) version installed.

Yes, I just build it with /usr/bin/python, and it works fine.   

Assuming

you have Xcode 3.2 installed.

Bill

Ugh, this is getting messy...

I think that I have built libfreetype.dylib and libjpeg.dylib as
i386 and x86_64 libs...at least that is what the file command asserts.

I then built the PIL package using the system python in 64 bit mode and
installed the rascal in the Apple python. All of the libs appear to be
multi-architecture ppc, i386 and x86_64

When I run apple python in 64 bit mode I can run the PIL demos...

If I restrict apple python to 32 bit mode all of the programs fail
with a bus error.

*********

I then tried to build PIL using the 2.6.2 python from python.org.
1) It would not build under gcc-4.2 I had to define CC=gcc-4.0
    the build appeared to succeed and I installed the PIL system.
2) All of the demos failed...

I noticed that _imagingtk.so was dynamically linked against
the ActiveState Tcl/Tk that is installed in /Library/Frameworks/
Tcl.framework

[mbp:/Library/Python/2.6/site-packages/PIL]$ otool -L _imagingtk.so
_imagingtk.so:
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility  
version 8.5.0, current version 8.5.4)
/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility  
version 8.5.0, current version 8.5.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 124.1.1)

I suppose that I could hide the ActiveState versions by renaming the  
Frameworks...

But even if I did that, how could I force setup.py to use the apple  
8.4 tcl/tk system instead
of the 'current' 8.5 system?

Any suggestions as to how I can get PIL to work when apple python is  
in 32 bit mode?

Any suggestions as to how I can build PIL using the 2.6.2 version of  
Python from python.org?

This is getting ugly...too many impedance mismatches.

Jerry

A little more success to report. ..

I hid the activestate tcl/tk frameworks in /Library/Frameworks and set CC to gcc-4.0

and rebuilt PIL and otool showed that _imagingtk.so was linked against the apple 8.4

Tcl/Tk system.

So I installed the build and "tada" Imaging appears to be working in python.org version

of python (2.6.2).

So this leaves only the "why does apple python (2.6.1) not work when run in 32 bit mode

but does in 64 bit mode"  question open...

Has anyone had success with PIL in this case?

Thanks 

Jerry

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Jerry LeVan]

On Oct 2, 2009, at 7:40 PM, Bill Janssen wrote:

Jerry LeVan <jerry.levan@...> wrote:

Is building PIL on Snow Leopard 'easy' I have the apple python  

(32/64)

installed and the python.org 2.6.2 (32 bit) version installed.

Yes, I just build it with /usr/bin/python, and it works fine.   

Assuming

you have Xcode 3.2 installed.

Bill

Ugh, this is getting messy...

I think that I have built libfreetype.dylib and libjpeg.dylib as
i386 and x86_64 libs...at least that is what the file command asserts.

I then built the PIL package using the system python in 64 bit mode and
installed the rascal in the Apple python. All of the libs appear to be
multi-architecture ppc, i386 and x86_64

When I run apple python in 64 bit mode I can run the PIL demos...

If I restrict apple python to 32 bit mode all of the programs fail
with a bus error.

*********

I then tried to build PIL using the 2.6.2 python from python.org.
1) It would not build under gcc-4.2 I had to define CC=gcc-4.0
    the build appeared to succeed and I installed the PIL system.
2) All of the demos failed...

I noticed that _imagingtk.so was dynamically linked against
the ActiveState Tcl/Tk that is installed in /Library/Frameworks/
Tcl.framework

[mbp:/Library/Python/2.6/site-packages/PIL]$ otool -L _imagingtk.so
_imagingtk.so:
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility  
version 8.5.0, current version 8.5.4)
/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility  
version 8.5.0, current version 8.5.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 124.1.1)

I suppose that I could hide the ActiveState versions by renaming the  
Frameworks...

But even if I did that, how could I force setup.py to use the apple  
8.4 tcl/tk system instead
of the 'current' 8.5 system?

Any suggestions as to how I can get PIL to work when apple python is  
in 32 bit mode?

Any suggestions as to how I can build PIL using the 2.6.2 version of  
Python from python.org?

This is getting ugly...too many impedance mismatches.

Jerry

A little more success to report. ..

I hid the activestate tcl/tk frameworks in /Library/Frameworks and set CC to gcc-4.0

and rebuilt PIL and otool showed that _imagingtk.so was linked against the apple 8.4

Tcl/Tk system.

So I installed the build and "tada" Imaging appears to be working in python.org version

of python (2.6.2).

So this leaves only the "why does apple python (2.6.1) not work when run in 32 bit mode

but does in 64 bit mode"  question open...

Has anyone had success with PIL in this case?

Thanks 

Jerry

When I run the Apple Python in 32  bit mode I get a bus error at the same place when I try

to display an image using PIL .  Here is part of the dump.

Exception Type:  EXC_BAD_ACCESS (SIGBUS)

Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000028

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread

0   com.tcltk.tklibrary           0x13a1850b Tk_GetImageMasterData + 17

1   com.tcltk.tklibrary           0x13a20cab Tk_FindPhoto + 37

2   _imagingtk.so                 0x007faacf PyImagingPhotoPut + 95

3   com.tcltk.tcllibrary           0x138d3d64 TclInvokeStringCommand + 101

4   com.tcltk.tcllibrary           0x00489977 Tcl_CreateInterp + 4919

5   com.tcltk.tcllibrary           0x0048a96c Tcl_EvalObjv + 72

6   _tkinter.so                   0x001e449d Tkapp_CallDeallocArgs + 11750

7   org.python.python             0x0008b372 PyEval_EvalFrameEx + 16375

8   org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

9   org.python.python             0x0008b591 PyEval_EvalFrameEx + 16918

10  org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

11  org.python.python             0x0002ee2c PyClassMethod_New + 1823

12  org.python.python             0x0000c700 PyObject_Call + 101

13  org.python.python             0x0001c12e PyClass_New + 1603

14  org.python.python             0x0000c700 PyObject_Call + 101

15  org.python.python             0x0008677a PyEval_CallObjectWithKeywords + 171

16  org.python.python             0x0001ba58 PyInstance_New + 290

17  org.python.python             0x0000c700 PyObject_Call + 101

18  org.python.python             0x0008c802 PyEval_EvalFrameEx + 21639

19  org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

20  org.python.python             0x0002ee2c PyClassMethod_New + 1823

21  org.python.python             0x0000c700 PyObject_Call + 101

22  org.python.python             0x0001c12e PyClass_New + 1603

23  org.python.python             0x0000c700 PyObject_Call + 101

24  org.python.python             0x0008677a PyEval_CallObjectWithKeywords + 171

25  org.python.python             0x0001ba58 PyInstance_New + 290

26  org.python.python             0x0000c700 PyObject_Call + 101

27  org.python.python             0x0008c802 PyEval_EvalFrameEx + 21639

28  org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

29  org.python.python             0x0008d009 PyEval_EvalCode + 87

30  org.python.python             0x000a40bb Py_CompileString + 111

31  org.python.python             0x000a4167 PyRun_FileExFlags + 139

32  org.python.python             0x000a5e8a PyRun_SimpleFileExFlags + 814

33  org.python.python             0x000b3168 Py_Main + 3074

34  org.python.python.app         0x00001eb5 start + 53

The crash occurs at the same 'place' every time...

If I run the Apple Python in 64 bit mode or the python.org Python ( 32 bit carbon 2.6.2 )image displaying, ie PIL,  works fine :)

Sorta strange...

Here is a sample program that can be used...

#!/usr/bin/env python  

# Author: Jerry LeVan

from Tkinter import *

import Image, ImageTk

import StringIO

from tkMessageBox import *

class ShowImage:

 

  def build_scrolled_canvas(self,parent):

     canvas=Canvas(parent)              

              

     sy = Scrollbar(parent, command=canvas.yview)

     sx = Scrollbar(parent, orient=HORIZONTAL,

                    command= canvas.xview)

     canvas.configure(yscrollcommand=sy.set,xscrollcommand=sx.set)                    

     canvas.grid(row=0,column=0,sticky=NSEW)

     sy.grid(row=0,column=1,stick=N+S)

     sx.grid(row=1,column=0,sticky=E+W)

     parent.columnconfigure(0,weight=1)

     parent.rowconfigure(0,weight=1)

     return canvas

  def __init__(self, theStr):

    self.theStr = theStr 

    self.theWin = Toplevel()

    self.theWin.title('Image Viewer')

    self.theFrame = Frame(self.theWin)

    self.theCanvas = self.build_scrolled_canvas(self.theFrame)

    self.theButton= Button(self.theWin,text="Close",command=self.theWin.destroy)

    self.theFrame.pack(side=TOP, expand=TRUE, fill=BOTH)

    self.theButton.pack(side=TOP)

    try:

         self.im = Image.open(StringIO.StringIO(self.theStr))

         (width,height) = self.im.size

         self.tkim = ImageTk.PhotoImage(self.im)

         self.theCanvas.create_image(0,0,image=self.tkim,anchor=NW)

         self.theCanvas['scrollregion'] = (0,0,width,height)

    except Exception, e :

         showerror(title="Error",message="image problem: "+str(e))

         self.theWin.destroy()

if __name__ == '__main__':

    theStr = open(sys.argv[1],'rb').read()

    thePic = ShowImage(theStr)

    myPic = ShowImage(theStr)

    mainloop()

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Jerry LeVan]

On Oct 2, 2009, at 7:40 PM, Bill Janssen wrote:

Jerry LeVan <jerry.levan@...> wrote:

Is building PIL on Snow Leopard 'easy' I have the apple python  

(32/64)

installed and the python.org 2.6.2 (32 bit) version installed.

Yes, I just build it with /usr/bin/python, and it works fine.   

Assuming

you have Xcode 3.2 installed.

Bill

Ugh, this is getting messy...

I think that I have built libfreetype.dylib and libjpeg.dylib as
i386 and x86_64 libs...at least that is what the file command asserts.

I then built the PIL package using the system python in 64 bit mode and
installed the rascal in the Apple python. All of the libs appear to be
multi-architecture ppc, i386 and x86_64

When I run apple python in 64 bit mode I can run the PIL demos...

If I restrict apple python to 32 bit mode all of the programs fail
with a bus error.

*********

I then tried to build PIL using the 2.6.2 python from python.org.
1) It would not build under gcc-4.2 I had to define CC=gcc-4.0
    the build appeared to succeed and I installed the PIL system.
2) All of the demos failed...

I noticed that _imagingtk.so was dynamically linked against
the ActiveState Tcl/Tk that is installed in /Library/Frameworks/
Tcl.framework

[mbp:/Library/Python/2.6/site-packages/PIL]$ otool -L _imagingtk.so
_imagingtk.so:
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility  
version 8.5.0, current version 8.5.4)
/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility  
version 8.5.0, current version 8.5.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 124.1.1)

I suppose that I could hide the ActiveState versions by renaming the  
Frameworks...

But even if I did that, how could I force setup.py to use the apple  
8.4 tcl/tk system instead
of the 'current' 8.5 system?

Any suggestions as to how I can get PIL to work when apple python is  
in 32 bit mode?

Any suggestions as to how I can build PIL using the 2.6.2 version of  
Python from python.org?

This is getting ugly...too many impedance mismatches.

Jerry

A little more success to report. ..

I hid the activestate tcl/tk frameworks in /Library/Frameworks and set CC to gcc-4.0

and rebuilt PIL and otool showed that _imagingtk.so was linked against the apple 8.4

Tcl/Tk system.

So I installed the build and "tada" Imaging appears to be working in python.org version

of python (2.6.2).

So this leaves only the "why does apple python (2.6.1) not work when run in 32 bit mode

but does in 64 bit mode"  question open...

Has anyone had success with PIL in this case?

Thanks 

Jerry

When I run the Apple Python in 32  bit mode I get a bus error at the same place when I try

to display an image using PIL .  Here is part of the dump.

Exception Type:  EXC_BAD_ACCESS (SIGBUS)

Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000028

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread

0   com.tcltk.tklibrary           0x13a1850b Tk_GetImageMasterData + 17

1   com.tcltk.tklibrary           0x13a20cab Tk_FindPhoto + 37

2   _imagingtk.so                 0x007faacf PyImagingPhotoPut + 95

3   com.tcltk.tcllibrary           0x138d3d64 TclInvokeStringCommand + 101

4   com.tcltk.tcllibrary           0x00489977 Tcl_CreateInterp + 4919

5   com.tcltk.tcllibrary           0x0048a96c Tcl_EvalObjv + 72

6   _tkinter.so                   0x001e449d Tkapp_CallDeallocArgs + 11750

7   org.python.python             0x0008b372 PyEval_EvalFrameEx + 16375

8   org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

9   org.python.python             0x0008b591 PyEval_EvalFrameEx + 16918

10  org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

11  org.python.python             0x0002ee2c PyClassMethod_New + 1823

12  org.python.python             0x0000c700 PyObject_Call + 101

13  org.python.python             0x0001c12e PyClass_New + 1603

14  org.python.python             0x0000c700 PyObject_Call + 101

15  org.python.python             0x0008677a PyEval_CallObjectWithKeywords + 171

16  org.python.python             0x0001ba58 PyInstance_New + 290

17  org.python.python             0x0000c700 PyObject_Call + 101

18  org.python.python             0x0008c802 PyEval_EvalFrameEx + 21639

19  org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

20  org.python.python             0x0002ee2c PyClassMethod_New + 1823

21  org.python.python             0x0000c700 PyObject_Call + 101

22  org.python.python             0x0001c12e PyClass_New + 1603

23  org.python.python             0x0000c700 PyObject_Call + 101

24  org.python.python             0x0008677a PyEval_CallObjectWithKeywords + 171

25  org.python.python             0x0001ba58 PyInstance_New + 290

26  org.python.python             0x0000c700 PyObject_Call + 101

27  org.python.python             0x0008c802 PyEval_EvalFrameEx + 21639

28  org.python.python             0x0008cf64 PyEval_EvalCodeEx + 1720

29  org.python.python             0x0008d009 PyEval_EvalCode + 87

30  org.python.python             0x000a40bb Py_CompileString + 111

31  org.python.python             0x000a4167 PyRun_FileExFlags + 139

32  org.python.python             0x000a5e8a PyRun_SimpleFileExFlags + 814

33  org.python.python             0x000b3168 Py_Main + 3074

34  org.python.python.app         0x00001eb5 start + 53

The crash occurs at the same 'place' every time...

If I run the Apple Python in 64 bit mode or the python.org Python ( 32 bit carbon 2.6.2 )image displaying, ie PIL,  works fine :)

Sorta strange...

Here is a sample program that can be used...

#!/usr/bin/env python  

# Author: Jerry LeVan

from Tkinter import *

import Image, ImageTk

import StringIO

from tkMessageBox import *

class ShowImage:

 

  def build_scrolled_canvas(self,parent):

     canvas=Canvas(parent)              

              

     sy = Scrollbar(parent, command=canvas.yview)

     sx = Scrollbar(parent, orient=HORIZONTAL,

                    command= canvas.xview)

     canvas.configure(yscrollcommand=sy.set,xscrollcommand=sx.set)                    

     canvas.grid(row=0,column=0,sticky=NSEW)

     sy.grid(row=0,column=1,stick=N+S)

     sx.grid(row=1,column=0,sticky=E+W)

     parent.columnconfigure(0,weight=1)

     parent.rowconfigure(0,weight=1)

     return canvas

  def __init__(self, theStr):

    self.theStr = theStr 

    self.theWin = Toplevel()

    self.theWin.title('Image Viewer')

    self.theFrame = Frame(self.theWin)

    self.theCanvas = self.build_scrolled_canvas(self.theFrame)

    self.theButton= Button(self.theWin,text="Close",command=self.theWin.destroy)

    self.theFrame.pack(side=TOP, expand=TRUE, fill=BOTH)

    self.theButton.pack(side=TOP)

    try:

         self.im = Image.open(StringIO.StringIO(self.theStr))

         (width,height) = self.im.size

         self.tkim = ImageTk.PhotoImage(self.im)

         self.theCanvas.create_image(0,0,image=self.tkim,anchor=NW)

         self.theCanvas['scrollregion'] = (0,0,width,height)

    except Exception, e :

         showerror(title="Error",message="image problem: "+str(e))

         self.theWin.destroy()

if __name__ == '__main__':

    theStr = open(sys.argv[1],'rb').read()

    thePic = ShowImage(theStr)

    myPic = ShowImage(theStr)

    mainloop()

Bah, Humbug...

I used otool to peek at _imagetk.so and found that the linker had picked up the ActiveState Tcl/tk Frameworks in /Library/Frameworks...

So I hid the active state frameworks for tcl and tk and just to be safe I hid the community python from python.org.

I made sure that the Apple Python was in my path and rebuilt PIL. This time it appears that  all is well. The Apple frameworks for

Tcl and Tk were picked up :)

I have been able to use PIL to  display images via Apple's Python running in 64 or 32 bit mode. 

I have a better handle on my WxPython problem...I think I was releasing a table for a grid a bit too soon...

Things are starting to look up :)

Jerry

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig