[Numpy-discussion] numpy distutils breaks scipy install on mac

[Mark Sienkiewicz]

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.