[Pythonmac-SIG] Fwd: distutils and stdarg.h

[Ned Deily]

In article <rowen-D2392E.14473313022012 at news.gmane.org>,
 "Russell E. Owen" <rowen at uw.edu> wrote:

> In article <nad-FFA1B0.21415009022012 at news.gmane.org>,
>  Ned Deily <nad at acm.org> wrote:
> 
> > In article <rowen-ACAA42.11370509022012 at news.gmane.org>,
> >  "Russell E. Owen" <rowen at 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,
 nad at acm.org