[Python-Dev] OS X Installer for 3.0.1 and supported versions (original) (raw)

Ned Deily nad at acm.org
Fri Feb 27 01:57:34 CET 2009

In article <rowen-8731E0.13531325022009 at news.gmane.org>, "Russell E. Owen" <rowen at 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, nad at acm.org

More information about the Python-Dev mailing list