In article rowen-d2392e.14473313022...@news.gmane.org,
Russell E. Owen ro...@uw.edu wrote:
In article nad-ffa1b0.21415009022...@news.gmane.org,
Ned Deily n...@acm.org wrote:
In article rowen-acaa42.11370509022...@news.gmane.org,
Russell E. Owen ro...@uw.edu wrote:
I suggest you try one of these things:
- Use gcc 4.0.1 to build extensions for 32-bit python.org python. That's
what I'm still doing. It requires XCode 3.x.
Yes.
- Use gcc 4.2.1 to build extensions for 64-bit python.org python. Two
issues:
- you give up compatibility with MacOS X 10.5.
- The result will not work with ActiveState's Tcl/Tk. Not a problem
for you, but both of these are unacceptable for my code.
I don't understand what you mean by this. The python.org 64-/32-bit
installers have a deployment target of 10.6 so will only work on 10.6
and 10.7 but they should work just fine with ActiveState's Tcl/Tk 8.5.x
on 10.6 and 10.7, just not on 10.5. In fact, the installers are built
and tested on systems with A/S Tcl/Tk 8.5.x and are their use is
virtually required on 10.6 for any Tkinter applications due to the
broken state of the Apple-supplied in Tcl/Tk 8.5.x in 10.6 (the
Apple-supplied Tcl/Tk 8.5.x is better in 10.7 but still behind the A/S
version wrt critical fixes.)
http://www.python.org/download/mac/tcltk/
Interesting and promising. The reason I thought python.org's 64-bit
python was strange w.r.t. ActiveState Tcl/Tk is explained in a copy of a
posting I sent to the matplotlib mailing list 2011-10-12 (appended).
Keven Walzer suggested the following, which now that I reread it does
not implicate the Python in any way, so I apologize.
With Tk-Cocoa, typically you see this message when mixing libraries that
are linked to the system Tk in /System/Library/Frameworks/Tk.framework
and another installation (typically ActiveTcl) in
/Library/Frameworks/Tk.framework. OS X gets confused and crashes with
that error message.
The only solution I've found is by making sure that all of your
Tk-linked libraries link to one location or the other. You can do this
by running otool -L on the relevant binaries and seeing where things are
linked. If you're only seeing this issue now after building matplotlib,
then it's logical to assume that matplotlib may have been linked to the
wrong library. You can change the linking by running install_name_tool
to get matplotlib to point to the correct version of Tk.
His suggestion will almost certainly work, but it seems unfortunate to
have to run install_name_tool to fix the matplotlib binaries. Perhaps I
could have hidden the system Tcl/Tk before building matplotlib, but
again it seems unfortunate to need to do that.
Any idea, perchance, on how to fix the underlying problem?
You *may* have run into a bug I've noticed a while back in Xcode 3.2.6.
The Xcode installer appears to screw up the symlinks to /Library within
/Developer/SDKs. The net effect is that frameworks installed in
/Library, like A/S Tcl and Tk, are not found during a build using the
SDK as they should be.
$ cd /Developer/SDKs/MacOSX10.6.sdk/Library
$ ls -l
total 8
lrwxr-xr-x 1 root wheel 19 Mar 17 18:24 Frameworks@ -
/Library/Frameworks
it ends up with an extra Frameworks directory so that
/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks/Frameworks/ -
/Library/Frameworks
The solution is to manually go in and fix the symlinks in
/Developer/SDKs/MacOSX10.6.sdk, and remember to do so again if you have
to reinstall Xcode 3.2.6. AFAIK, this bug is unique to Xcode 3.2.6, not
earlier versions of 3.2.x.
--
Ned Deily,
n...@acm.org
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
