In article <rowen-8731e0.13531325022...@news.gmane.org>,
 "Russell E. Owen" <ro...@u.washington.edu> wrote:
> I want to follow up on this a bit. In the past if the Mac Python 
> installer was built on a machine that did NOT have a locally installed 
> Tcl/Tk then it would fail to work with a locally installed Tcl/Tk: 
> Python would segfault when trying to use Tkinter.
> 
> The solution was to build the Mac python installer on a machine with a 
> locally installed Tcl/Tk. The resulting installer package would work on 
> all systems -- with or without locally installed Tcl/Tk.
> 
> So...has this problem been worked around, or is the Mac installer still 
> built on a machine that has a locally installed Tcl/Tk?

Ronald will have to answer that for sure since he built the installer 
for 3.0.1.

However, it seems to be true that the most recent python.org OS X 
installers will always favor a /System/Library/Frameworks/{Tcl/Tk}:

$ cd 
/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib-dynlo
ad
$ otool -L _tkinter.so 
_tkinter.so:
   /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl 
(compatibility version 8.4.0, current version 8.4.0)
   /System/Library/Frameworks/Tk.framework/Versions/8.4/Tk 
(compatibility version 8.4.0, current version 8.4.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.3.10)

I'm certainly not a Tcl expert nor overly familiar with the history of 
this issue but here's what I see.  As a test, I installed the ActiveTcl 
8.4.19, which installs in /Library/Frameworks, and confirmed that a 
simple "import tkinter; root = tkinter.Tk()" for 3.0.1 does indeed use 
the Apple-supplied 8.4.7 Tcl.

Running similar tests and otool -L on _tkinter.so from the 2.6.1 and 
2.5.4 python.org installs gives similar results (both always use the 
Apple-supplied Tcl from /System/Library).  

However, the _tkinter.so from the 2.4.4 python.org installer is 
different:
$ cd 
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-dynlo
ad
$ otool -L _tkinter.so 
_tkinter.so:
   /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility 
version 8.4.0, current version 8.4.13)
   /Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility 
version 8.4.0, current version 8.4.13)
   /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 
47.1.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.1.3)

and it does in fact use the /Library 8.4.19 ActiveTcl framework if 
installed and, as expected, reverts to the Apple-supplied 8.4.7 
/System/Library framework version if the ActiveTcl framework is removed.

So it looks like you recall correctly that at least some earlier 
installers were built on a machine with a locally installed Tcl/Tk.  It 
should be an easy matter to do that for future 10.4-10.5 installers so 
that newer 8.4 versions can be used.

Note, there was a Tcl/Tk problem with the initial 2.6 OS X installer 
(http://bugs.python.org/issue4017) but in that case the locally 
installed Tcl/Tk version was 8.5 and the fallback to a system-supplied 
8.4 doesn't work across versions.

> Most people who makes serious use of Tkinter presumably have a locally 
> installed Tcl/Tk because the version that Apple provides is ancient and 
> is missing many important bug fixes and performance enhancements.
> 
> Also, a somewhat related issue: Tcl/Tk 8.4 is no longer maintained. All 
> development work is going on in Tcl/Tk 8.5. Presumably Apple will 
> transition one of these days, and at that point we may need a separate 
> Mac Python installer for the older operating systems vs. the newer.

Yes, something will need to be done for that if Snow Leopard does have 
newer versions.

Thanks for bringing this up!

-- 
 Ned Deily,
 n...@acm.org

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to