Pip / easy_install ignoring ARCHFLAGS in SciPy install?

I am trying to compile SciPy for both 32 bit and 64 bit architecture as some of the applications that use the library are only one arch or the other, following the advice of a few stackoverflow questions . This command worked for me in a similar build about two months ago, but now it seems that some of the compiled shared libraries are only for x86_64:

sudo ARCHFLAGS="-arch i386 -arch x86_64" pip install scipy

I've tried several versions of this command, including setting environment variables before sudo

including -m32 -m64

in FFlags using the OSX Command Line Tools, a full install of Xcode using clang instead of LLVM that comes with OSX after SciPy 's official installation instructions , easy_install instead of pip, and even. / configure 'ing separately, etc., but I can't seem to get it to work. Oddly enough, some of the .so are built on both architectures, but some of them are not:

dhcp-10-249-71-202:~ kastman$ file /Library/Python/2.7/site-packages/scipy/optimize/*.so
/Library/Python/2.7/site-packages/scipy/optimize/_cobyla.so:   Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/_lbfgsb.so:   Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/_minpack.so:  Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/_nnls.so:     Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/_slsqp.so:    Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/_zeros.so:    Mach-O universal binary with 2 architectures
/Library/Python/2.7/site-packages/scipy/optimize/_zeros.so (for architecture i386): Mach-O bundle i386
/Library/Python/2.7/site-packages/scipy/optimize/_zeros.so (for architecture x86_64):   Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/minpack2.so:  Mach-O 64-bit bundle x86_64
/Library/Python/2.7/site-packages/scipy/optimize/moduleTNC.so: Mach-O universal binary with 2 architectures
/Library/Python/2.7/site-packages/scipy/optimize/moduleTNC.so (for architecture i386):  Mach-O bundle i386
/Library/Python/2.7/site-packages/scipy/optimize/moduleTNC.so (for architecture x86_64):    Mach-O 64-bit bundle x86_64

      

Looking at the make log, it looks like the arguments are passed successfully both for libraries that work and for those that don't:

# Minpack doesn't build fat binaries
/usr/local/bin/gfortran -Wall -Wall -undefined dynamic_lookup -bundle build/temp.macosx-10.7-intel-2.7/build/src.macosx-10.7-intel-2.7/scipy/optimize/minpack2/minpack2module.o build/temp.macosx-10.7-intel-2.7/build/src.macosx-10.7-intel-2.7/fortranobject.o build/temp.macosx-10.7-intel-2.7/scipy/optimize/minpack2/dcsrch.o build/temp.macosx-10.7-intel-2.7/scipy/optimize/minpack2/dcstep.o -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin11/4.6.2 -Lbuild/temp.macosx-10.7-intel-2.7 -lgfortran -o build/lib.macosx-10.7-intel-2.7/scipy/optimize/minpack2.so
building 'scipy.optimize._slsqp' extension
compiling C sources
C compiler: clang -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe

#... but moduleTNC does.
llvm-gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -Wl,-F. -arch i386 -arch x86_64 build/temp.macosx-10.7-intel-2.7/scipy/optimize/tnc/moduleTNC.o build/temp.macosx-10.7-intel-2.7/scipy/optimize/tnc/tnc.o -Lbuild/temp.macosx-10.7-intel-2.7 -o build/lib.macosx-10.7-intel-2.7/scipy/optimize/moduleTNC.so
building 'scipy.optimize._cobyla' extension
compiling C sources
C compiler: clang -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe

      

Is it possible that the difference is in the gfortran compiler I am using? I have used brew install gfortran

which should be good according to SciPy documentation. I would have thought that the important line would be the C-compiler: clang line , which seems to be almost identical, including -arch.

The last most detailed build I tried was:

sudo env ARCHFLAGS="-arch i386 -arch x86_64" ARCH="i386 x86_64" CC="clang" CXX="clang" FFLAGS="-ff2c -m32 -m64" pip install scipy

Does anyone have any suggestions for further diagnosing this?

(OSX 10.7, recent MacBookPro, compiling with gcc from CLI tools and from Xcode)

+3


source to share


1 answer


Pulling from source and building seems to be creating live binaries correctly. I'm not sure if this is a bug that's been fixed already (I didn't see anything on scipy dev's list), or if it's pip / easy_install related, but here's what I did to get it to work:

git clone https://github.com/scipy/scipy.git; cd scipy
export ARCHFLAGS='-arch i386 -arch x86_64'
python setup.py config
python setup.py build
sudo python setup.py install

      



There are no special CC environment variables, gfortran was from brew install gfortran

, and surprisingly it looks like gcc was llvm-gcc.

+3


source







All Articles