[SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1

Charles R Harris charlesr.harris@gmail....
Fri Nov 6 18:10:12 CST 2009


On Fri, Nov 6, 2009 at 4:41 PM, David Warde-Farley <dwf@cs.toronto.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091106/cb64178c/attachment.html 


More information about the Scipy-dev mailing list