When I compile scipy on a mac, the build fails with:
...
gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
error: Command "/sw/bin/gfortran -Wall -ffixed-form
-fno-second-underscore -arch i686 -arch x86_64 -fPIC -O3 -funroll-loops
-I/usr/stsci/pyssgdev/2.5.4/numpy/core/include -c -c
scipy/fftpack/src/dfftpack/dcosqb.f -o
build/temp.macosx-10.3-i386-2.5/scipy/fftpack/src/dfftpack/dcosqb.o"
failed with exit status 1
I have
% gfortran --version
GNU Fortran (GCC) 4.3.0
Copyright (C) 2008 Free Software Foundation, Inc.
% which gfortran
/sw/bin/gfortran
(This /sw/bin apparently means it was installed by "fink". My IT
department did this. This is not the recommended compiler from AT&T,
but it seems a likely configuration to encounter in the wild, and I
didn't expect a problem. )
I traced the problem to numpy/distutils/fcompiler/gnu.py in the class
Gnu94FCompiler. The function _universal_flags() tries to detect which
processor types are recognized by the compiler, presumably in an attempt
to make a macintosh universal binary. It adds "-arch whatever" for each
architecture that it thinks it detected. Since gfortran does not
recognize "-arch", the compile fails.
( Presumably, some other version of gfortan does accept -arch, or this
code wouldn't be here, right? )
The function _can_target() attempts to recognize what architectures the
compiler is capable of by passing in -arch parameters with various known
values, but gfortran does not properly indicate a problem in a way that
_can_target() can detect:
% gfortran -arch i386 hello_world.f
f951: error: unrecognized command line option "-arch"
% gfortran -arch i386 -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.3.0/configure --prefix=/sw
--prefix=/sw/lib/gcc4.3 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --build=i686-apple-darwin9 --with-gmp=/sw
--with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib
Thread model: posix
gcc version 4.3.0 (GCC)
% echo $status
0
%
That is, when you say "-v", it gives no indication that it doesn't
understand the -arch flag.
I didn't ask for a universal binary and I don't need one, so I'm
surprised that it is trying to make one for me. I think the correct
solution is that _universal_flag() should not add -arch flags unless the
user specifically requests one. Unfortunately, I can't write a patch,
because I don't have the time it would take to reverse engineer
distutils well enough to know how to do it.
As is usual when a setup.py auto-detects the wrong compiler flags, the
easiest solution is to create a shell script that looks like the
compiler, but add/removes flags as necessary:
% cat /eng/ssb/auto/prog/binhacks/scipy.osx/gfortran
#!/bin/sh
args=""
for x in $*
do
case "$x"
in
-arch)
shift
shift
;;
*)
args="$args $x"
;;
esac
done
/sw/bin/gfortran $args
Mark S.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
