Issue9045
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2010-06-21 18:02 by srid, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (15) | |||
---|---|---|---|
msg108292 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2010-06-21 18:02 | |
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 $ |
|||
msg108318 - (view) | Author: Ned Deily (ned.deily) * ![]() |
Date: 2010-06-21 20:55 | |
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. |
|||
msg108339 - (view) | Author: Ronald Oussoren (ronaldoussoren) * ![]() |
Date: 2010-06-22 06:20 | |
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. |
|||
msg108555 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2010-06-24 22:19 | |
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" |
|||
msg108602 - (view) | Author: Roland Johnson (RolandJ) | Date: 2010-06-25 14:43 | |
Does this also relate to 3.1? Tkinter in not installing for that version under 10.6.4 |
|||
msg108605 - (view) | Author: Ronald Oussoren (ronaldoussoren) * ![]() |
Date: 2010-06-25 15:13 | |
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. |
|||
msg108610 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2010-06-25 16:28 | |
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. |
|||
msg108784 - (view) | Author: Ronald Oussoren (ronaldoussoren) * ![]() |
Date: 2010-06-27 12:48 | |
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. |
|||
msg108852 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2010-06-28 18:31 | |
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 |
|||
msg108859 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2010-06-28 20:32 | |
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 |
|||
msg108882 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2010-06-29 00:15 | |
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. |
|||
msg127129 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2011-01-26 19:03 | |
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? |
|||
msg127130 - (view) | Author: Sridhar Ratnakumar (srid) | Date: 2011-01-26 19:13 | |
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. |
|||
msg127145 - (view) | Author: Ned Deily (ned.deily) * ![]() |
Date: 2011-01-26 21:16 | |
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. |
|||
msg130416 - (view) | Author: Ned Deily (ned.deily) * ![]() |
Date: 2011-03-09 03:55 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:02 | admin | set | github: 53291 |
2011-03-09 03:55:42 | ned.deily | set | status: open -> closed nosy: terry.reedy, ronaldoussoren, ned.deily, srid, RolandJ messages: + msg130416 assignee: ronaldoussoren -> ned.deily resolution: out of date stage: resolved |
2011-02-03 22:48:54 | belopolsky | set | nosy:
terry.reedy, ronaldoussoren, ned.deily, srid, RolandJ type: crash -> behavior components: + Build |
2011-01-26 21:16:16 | ned.deily | set | nosy:
terry.reedy, ronaldoussoren, ned.deily, srid, RolandJ messages: + msg127145 |
2011-01-26 19:13:52 | srid | set | nosy:
terry.reedy, ronaldoussoren, ned.deily, srid, RolandJ messages: + msg127130 |
2011-01-26 19:03:44 | terry.reedy | set | nosy:
+ terry.reedy messages: + msg127129 |
2010-06-29 00:15:52 | srid | set | messages: + msg108882 |
2010-06-28 20:32:27 | srid | set | messages: + msg108859 |
2010-06-28 18:31:17 | srid | set | messages: + msg108852 |
2010-06-27 12:48:29 | ronaldoussoren | set | messages: + msg108784 |
2010-06-25 16:28:51 | srid | set | messages: + msg108610 |
2010-06-25 15:13:14 | ronaldoussoren | set | messages:
+ msg108605 versions: + Python 3.2 |
2010-06-25 14:43:55 | RolandJ | set | nosy:
+ RolandJ messages: + msg108602 |
2010-06-24 22:19:48 | srid | set | messages: + msg108555 |
2010-06-22 06:20:42 | ronaldoussoren | set | messages: + msg108339 |
2010-06-21 20:55:25 | ned.deily | set | nosy:
+ ned.deily messages: + msg108318 |
2010-06-21 18:02:19 | srid | create |