/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
stdarg.h: No such file or directory

That file does exist, but it uses:

#include_next <stdarg.h>

So apparently there isn't a stdarg.h later on in the include path.

There are a LOT of versions of stdarg.h on my system, so it's less
than obvious which one should get picked up. Also, shouldn't distuitls
set the include dirs to get this anyway? Even if I find one that
works, I'd hate to hard-code that in there.

Re: distutils and stdarg.h

On 8 Feb, 2012, at 21:14, Chris Barker wrote:

> HI folks,
>
> I'm trying to build the Enthought Tool Suite "Enable" package
>
> (http://code.enthought.com/projects/index.php)
>
> against the python.org 32 bit Intel/PPC build of python 2.7
>
> I'm getting a bunch of errors like:
>
> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
> stdarg.h: No such file or directory
>
> That file does exist, but it uses:
>
> #include_next <stdarg.h>
>
> So apparently there isn't a stdarg.h later on in the include path.
>
> There are a LOT of versions of stdarg.h on my system, so it's less
> than obvious which one should get picked up. Also, shouldn't distuitls
> set the include dirs to get this anyway? Even if I find one that
> works, I'd hate to hard-code that in there.
>
> any thoughts?

What compiler version do you use? One thing you could try is to drop support for ppc, for example by adding ["-arch", "i386"] to extra_compiler_args in the definition of the Extension in setup.py. Recent Xcode releases do not include a compiler that supports the powerpc architecture.

> One thing you could try is to drop support for ppc, for example by adding ["-arch", "i386"] to extra_compiler_args in the definition of the Extension in setup.py.

I'll give that try, but ...

> Recent Xcode releases do not include a compiler that supports the powerpc architecture.

I've made a point of not upgrading XCode for that reason -- and I'm
not having trouble compiling PPC versions other extensions.

I'm pretty sure I've done both C and C++ ones, too.

I'm thinking that some of the standard stuff that distutils adds has
been overridden by this build -- it's a big, complicated setup, using
numpy, distutils, etc. I'm having trouble following it all (or
simplifying it -- I don't need the whole package anyway). Entought is
no longer testing on this distribution of Python, nor PPC at all, I
believe, so they could have inadvertently broken it easily enough.

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.

- 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.

- Use gcc 4.2.1 and ActiveState's 64-bit python 2.7. That supposedly
gives you compatibility with MacOS X 10.5 and it surely works with
ActiveState's Tcl/Tk. But you may need a license to distribute the
results (likely free in your case). This is the way I'm leaning, and I
even got a license, but I'm reluctant to give up on python.or python.

> - 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.)

Distutils *does* try to call the right CC compiler (that is, the
compiler the Python itself was built with), unless the
module/package/distribution's setup.py overrides it. If it is using C++
code, though, you may have to override that yourself since Python itself
does not contain any C++ code and I don't think there is any special
code in Distutils to override C++ stuff.

> 2) how do I use 4.01. with distutils?

For the any C++ modules, you may need to override the C++ compiler
choice by using a CXX environment variable.

Re: Fwd: distutils and stdarg.h

On Thu, Feb 9, 2012 at 12:55 PM, Ned Deily <[hidden email]> wrote:
>> 1) I thought distutils took care of calling the "right" compliler to
>> match what pyotn had been built with. I guess not.
>
> Distutils *does* try to call the right CC compiler (that is, the
> compiler the Python itself was built with), unless the
> module/package/distribution's setup.py overrides it.

it's possible that that's what's happening -- as I said, this is an
ugly complicated mess.

> If it is using C++
> code, though, you may have to override that yourself since Python itself
> does not contain any C++ code and I don't think there is any special
> code in Distutils to override C++ stuff.

That could be it, too.

>> 2) how do I use 4.01. with distutils?
>
> For the any C++ modules, you may need to override the C++ compiler
> choice by using a CXX environment variable.

Re: Fwd: distutils and stdarg.h

>> If it is using C++
>> code, though, you may have to override that yourself since Python itself
>> does not contain any C++ code and I don't think there is any special
>> code in Distutils to override C++ stuff.
>
> That could be it, too.
>
>>> 2) how do I use 4.01. with distutils?
>>
>> For the any C++ modules, you may need to override the C++ compiler
>> choice by using a CXX environment variable.
>
> OK -- I'll try that.

Bingo! I did:

$ export CXX=/usr/bin/g++-4.0

then

$ python setup.py build

and it built fine.

Actually, it chocked when it couldn't find the wxPython libs, but I
disab'ed that, as I don't need it right now -- and then it built fine.

Re: Fwd: distutils and stdarg.h

> In article <[hidden email]>,
> "Russell E. Owen" <[hidden email]> 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.

I would like to build matplotlib 1.1.0 (in fact I'd like to build an
official binary installer) and am running into problems. The build and
install goes fine, though with a few odd messages (see appended log).
But importing pylab rusults in:
objc[1083]: Class TKApplication is implemented in both
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two
will be used. Which one is undefined.
objc[1083]: Class TKMenu is implemented in both
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two
will be used. Which one is undefined.
objc[1083]: Class TKContentView is implemented in both
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two
will be used. Which one is undefined.
objc[1083]: Class TKWindow is implemented in both
/Library/Frameworks/Tk.framework/Versions/8.5/Tk and
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two
will be used. Which one is undefined.

Any idea how to deal with this? Google turned up others with this
problem but no obvious solution.

-- Russell

P.S. partial log of build (not install) of matplotlib:

Edit setupext.py to point it to Apple's built-in libraries, plus include
/usr/local (which doesn't have a lot in it --nothing in lib or includes):
'darwin' : ['/usr/local', '/usr', '/usr/X11'],

OPTIONAL BACKEND DEPENDENCIES
???????????????libpng: found, but unknown version (no pkg-config)
??????????????Tkinter: Tkinter: version not identified, Tk: 8.5, Tcl: 8.5
?????????????????Gtk+: no
???????????????????????* Building for Gtk+ requires pygtk; you must be
able
???????????????????????* to "import gtk" in your build/install
environment
??????Mac OS X native: yes
???????????????????Qt: no
??????????????????Qt4: no
????????????????Cairo: no

Re: Fwd: distutils and stdarg.h

> In article <[hidden email]>,
> Ned Deily <[hidden email]> wrote:
>
> > In article <[hidden email]>,
> > "Russell E. Owen" <[hidden email]> 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.

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.

Re: Fwd: distutils and stdarg.h

>...
> 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.

My symlinks are broken as you describe (though oddly
/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks contains both the
symlink Frameworks->Library/Frameworks that you mentioned and also
PluginManager.framework).