homepage

It appears that we are building 64-bit mac installer starting 2.7. For http://python.org/ftp/python/2.7/python-2.7rc1-macosx10.5-2010年06月07日.dmg
$ file /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: Mach-O universal binary with 2 architectures
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so (for architecture ppc7400): Mach-O bundle ppc
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so (for architecture i386): Mach-O bundle i386
$ python2.7 -c "import _tkinter"
Traceback (most recent call last):
 File "<string>", line 1, in<module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so, 2): no suitable image found. Did find:
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: no matching architecture in universal wrapper
$

I believe the issue was that there was no supported 64-bit non-X Tk available for 10.5. Has that changed? Otherwise, the build process and Tkinter need to be modified to dynamically link with more than one version of Tk, something that has been discussed but, AFAIK, not implemented.

A patch to fix this issue would be appreciated. However, there is are two reasons why _tkinter is build for 32-bit architectures only:
1) Apple didn't ship a 64-bit Tk until OSX 10.6, and that is Tk 8.5 while earlier releases of the OS use Tk 8.4
2) Tk 8.5 on OSX 10.6 seems to break IDLE, see Issue6864
Issue8798 describes a way to get a build that works on OSX 10.5 or later and still supports 64-bit Tk (on OSX 10.6 or when the user has installed a local 64-bit copy of Tk 6.5). I don't have time to work in this myself, which is why the issue is not very detailed.

We can make this work on OSX 10.6 atleast, using Apple's system Tcl/Tk 8.5.
1. Get a 10.6 build machine with 10.5 SDK
2. Modify setup.py to use openssl 0.9.7 (*not* 0.9.8):
 search_for_ssl_incs_in=['/Developer/SDKs/MacOSX10.5.sdk/usr/include/'] 
 [...]
 s/ libraries = ['ssl', 'crypto'] / 
 libraries = ['ssl.0.9.7', 'crypto.0.9.7'] /g
 
3. Run ./configure with MACOSX_DEPLOYMENT_TARGET=10.5 env variable
Catch: 10.5 users will have to install Tcl/Tk manually (eg: ActiveTcl 8.5) and run IDLE with "arch -i386 idle2.7"

Does this also relate to 3.1? Tkinter in not installing for that version under 10.6.4

AFAIK there is no 64-bit installer for 3.1. There will be one for 3.2.
Sridhar: building using the 10.5 SDK should also work by using --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk. I've recently patched setup.py and distutils to honor the SDK setting when looking for files.

On 2010年06月25日, at 8:13 AM, Ronald Oussoren wrote:
> Sridhar: building using the 10.5 SDK should also work by using --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk. I've recently patched setup.py and distutils to honor the SDK setting when looking for files.
Yes, but that will end up linking with Tcl/Tk 8.4 /inside/ the 10.5sdk; whereas the walkthrough above links to Apple's Tcl/Tk 8.5 built with 64-bit. I do hope - and I am not sure about this (though I have personally verified this by running regrtest) - using MACOSX_DEPLOYMENT_TARGET=10.5 will make the resultant binaries work on a 10.5 machine.

Even when building using an SDK you can use frameworks in /Library/Frameworks because $SDKROOT/Library/Frameworks is a symlink to the real /Library/Frameworks.

On 2010年06月27日, at 5:48 AM, Ronald Oussoren wrote:
> Even when building using an SDK you can use frameworks in /Library/Frameworks because $SDKROOT/Library/Frameworks is a symlink to the real /Library/Frameworks.
When building on 10.6, we are relying on Apple's Tcl/Tk 8.5 in /System/Library/Frameworks 
But 10.5 SDK only has Tcl/Tk 8.4 (i386+ppc) on a 10.6 machine:
$ ls -l /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Tcl.framework/Versions/
total 8
drwxr-xr-x 3 root wheel 170 19 Jan 18:21 8.4
lrwxr-xr-x 1 root wheel 3 19 Jan 18:19 Current -> 8.4
For Python 2.7, do you think it is possible to use the (64-bit) Tcl/Tk 8.5 from /System/Library/Framework when building with 10.5 SDK on a 10.6 machine?
-srid

I tried patching setup.py to force linking to Apple's Tcl/Tk:
--- python/setup.py.original	2010年06月28日 11:40:26.000000000 -0700
+++ python/setup.py	2010年06月28日 11:45:39.000000000 -0700
@@ -1682,6 +1682,15 @@
 for F in framework_dirs:
 # both Tcl.framework and Tk.framework should be present
 
+ # When building for 64-bit (presumably on 10.6, with 10.5 SDK),
+ # skip the SDK Tcl/Tk and instead use the one on /System/Library
+ # which is Apple's Tcl/Tk 8.5 with 64-bit.
+ if PT_CONFIG_mac_64bit:
+ F = '/System/Library/Frameworks/' # force Apple's one
+ for fw in 'Tcl', 'Tk':
+ if not exists(join(F, fw + '.framework')):
+ raise IOError('No %s found in %s' % (fw, F))
+ break
 
 for fw in 'Tcl', 'Tk':
 if is_macosx_sdk_path(F):
But unfortunately, even though we use 8.5 header files ... the link line uses `-isysroot`, thereby linking to 8.4:
gcc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -isysroot /Developer/SDKs/MacOSX10.5.sdk/ build/temp.macosx-10.5-intel-2.7/Users/sridharr/as/apy/trunk/build/pyhg_trunk-macosx-hgtip27/python/Modules/_tkinter.o build/temp.macosx-10.5-intel-2.7/Users/sridharr/as/apy/trunk/build/pyhg_trunk-macosx-hgtip27/python/Modules/tkappinit.o -L/Library/Frameworks/Python.framework/Versions/2.7/lib -o build/lib.macosx-10.5-intel-2.7/_tkinter.so -framework Tcl -framework Tk
ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks//Tk.framework/Tk, missing required architecture x86_64 in file
*** WARNING: renaming "_tkinter" since importing it failed: dlopen(build/lib.macosx-10.5-intel-2.7/_tkinter.so, 2): Symbol not found: _Tk_GetNumMainWindows

Here's one resolution:
1. Edit setup.py to make INCLUDE/LIB paths for OpenSSL use the SDKROOT (for 10.5+ compat):
[...]
search_for_ssl_incs_in = ["/Developer/SDKs/MacOSX10.5.sdk/usr/include/" if ON_SNOW_LEOPARD else "/usr/include"]
search_for_ssl_libs_in = ["/Developer/SDKs/MacOSX10.5.sdk/usr/lib/" if ON_SNOW_LEOPARD else "/usr/lib"]
2. Force the 10.5 SDK to use Apple's Tcl/Tk 8.5 (10.5 users must install ActiveTcl, and then launch Python as "arch -i386 python2.7" if they want to use tkinter):
$ sudo ln -s /System/Library/Frameworks/Tcl.framework /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/
$ sudo ln -s /System/Library/Frameworks/Tk.framework /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/
3. Build with 10.5 SDK
$ export MACOSX_DEPLOYMENT_TARGET=10.5
$ ./configure --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk/ --with-universal-archs=intel
$ make
And the result is a Python that works on 10.5+ and gives you 64-bit Tkinter for 10.6 users.
This is how I am intending to build ActivePython 2.7 this weekend.

I have the impression that there has been progress on tcl/tk on Apple in the last 7 months. Should this issue still be open, and if so, for both 2.7 and 3.2?

Terry J. Reedy wrote:
> Terry J. Reedy<tjreedy@udel.edu> added the comment:
>
> I have the impression that there has been progress on tcl/tk on Apple in the last 7 months. Should this issue still be open, and if so, for both 2.7 and 3.2?
 From http://www.python.org/download/mac/tcltk/ - it seems that 3.2's 
64-bit build will use ActiveTcl 8.5 that is now built with 64-bit. But 
2.7 still uses 8.4.

Terry, we are working on all of the OS X IDLE Tk issues at the moment with focus first on 3.2. These issues will be updated and closed as they are resolved.

The 2.7.1 python.org 64-/32-bit installer was changed to be built with a deployment target of 10.6 and linked with the Apple-supplied Cocoa Tk 8.5.7. Now that ActiveState has released a 64-bit version of Cocoa Tk 8.5 and one that is much more stable than the current Apple-supplied one, the recent Python 3.2 release includes a 64-/32-bit installer for 10.6 which links with it. The next release of 2.7 (2.7.2) will be similar. For the python.org installers, the current plans are to support 64-bit installers only for 10.6 and above, not 10.5.