On Fri, Nov 6, 2009 at 4:41 PM, David Warde-Farley <dwf@[...].edu> wrote:

>  On 6-Nov-09, at 4:53 PM, Charles R Harris wrote:
> 
>  > This looks like a confusion between the c/c++ complex.h files. They
>  > aren't
>  > the same. I'm beginning to think we need to back out the complex.h
>  > stuff
>  > until we can figure out a way to hide it, or at least keep the c
>  > version
>  > from getting confused with the c++ version.
> 
>  Sorry for the gratuitous errors, I should've deduplicated. Better too
>  much than too little, though. :)
> 
>  FWIW, when I switched to using gcc/g++/etc. 4.2, the problem goes
>  away, however there's yet another problem related to recent NumPy
>  mailing list traffic re: long double:
> 
> 
The include files may be differently set up between the two. I note the gnu
lists complex.h support as broken for all the 4.* versions currently out
there.


>  creating build/temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros
>  compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/
>  lib/python2.5/site-packages/numpy/core/include -c'
>  gcc: scipy/optimize/Zeros/bisect.c
>  cc1: error: unrecognized command line option "-Wno-long-double"
>  cc1: error: unrecognized command line option "-Wno-long-double"
>  lipo: can't figure out the architecture type of: /var/folders/jz/
>  jzMQLnV-GOWCP55tPgPBl++++Tc/-Tmp-//ccWBbydS.out
>  ...
>  error: Command "gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/
>  MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -
>  mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/
>  Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
>  numpy/core/include -c scipy/optimize/Zeros/bisect.c -o build/
>  temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros/bisect.o" failed with
>  exit status 1
> 
>  I will try removing -Wno-long-double from the appropriate places and
>  muddle through the build (I should note that I'm on a PPC machine
>  which may be one of the boundary cases where all of this long double
>  confusion is coming from.)
> 
> 
I suspect David (C) can fix this one. PPC has it's own, non-ieee, version of
long doubles and so is a bit of an outlier. It's a good thing that you are
building on the PPC during this work just to uncover the problems ;)

Chuck