Pip/easy_install 在 SciPy 安装中忽略 ARCHFLAGS? [英] Pip/easy_install ignoring ARCHFLAGS in SciPy installation?
问题描述
我正在尝试为 32 位和 64 位架构编译 SciPy，因为一些使用该库的应用程序只是一个架构，遵循来自 很少 SO 问题.大约两个月前，这个命令在类似的构建中对我有用，但现在似乎一些编译的共享库只针对 x86_64:
I'm trying to compile SciPy for both 32-bit and 64-bit architectures, since some of the applications that use the library are only one arch or the other, following advice from a few SO questions. This command has worked for me in a similar build about two months ago, but now it seems that some of the compiled shared libraries are only targeting x86_64:
sudo ARCHFLAGS="-arch i386 -arch x86_64" pip install scipy
我已经尝试了这个命令的几个版本，包括在 sudo 之前设置环境变量，包括 FFlags 中的 -m32 -m64，使用 OSX 命令行工具，完整的 Xcode 安装，使用 clang 而不是 OSX 随附的 LLVM，遵循 说明、easy_install 而不是pip 甚至./configure'ing 等，但我似乎无法让它工作.奇怪的是，有些 .so 正在构建两种架构，但有些则不是:
I've tried several versions of this command, including setting the environment variables before sudo, including -m32 -m64 in FFlags, using the OSX Command Line Tools, a full Xcode install, using clang instead of the LLVM that comes with OSX following the official SciPy install instructions, easy_install instead of pip and even ./configure'ing separately, etc., but I can't seem to get it to work. Oddly, some of the .so's are building with both architectures, but some 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
查看 make 日志，看起来似乎工作的库和不工作的库都成功传递了参数:
Looking at the make log, it looks like the args are being passed successfully for both the libraries that seem to work and 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
是否有可能是我使用的 gfortran 编译器有所不同?我使用了 brew install gfortran 根据 SciPy 文档应该是好的.我认为重要的一行是 C compiler: clang 行，它看起来几乎相同，包括 -arch 的.
Is it possible that the difference is the gfortran compiler I'm using? I used brew install gfortran which is supposed to be good according to the SciPy documentation. I would think the important line would be the C compiler: clang line, which appears to be nearly identical, including both -arch's.
我尝试过的最后一个最详细的构建是:
The last most detailed build I've 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 suggestions about how to further diagnose this?
(OSX 10.7，最近的 MacBookPro，使用来自 CLI 工具和 Xcode 的 gcc 编译)
(OSX 10.7, recent MacBookPro, compiling with gcc from the CLI tools and from Xcode)
推荐答案
从源和构建中拉取似乎可以正确创建胖二进制文件.我不确定这是否是一个已经修复的错误(我在 scipy 开发列表中没有看到任何内容)或者是否与 pip/easy_install 有关，但这是我为使其工作所做的工作:
Pulling from source and building appears to correctly create fat binaries. I'm not sure if this is a bug that's already been fixed (I didn't see anything on the scipy dev list) or if it has to do with pip/easy_install, 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
没有特殊的 CC 环境变量，gfortran 来自 brew install gfortran，令人惊讶的是 gcc 看起来像 llvm-gcc.
No special CC environment variables, gfortran was from brew install gfortran, and surprisingly it looks like gcc was llvm-gcc.
这篇关于Pip/easy_install 在 SciPy 安装中忽略 ARCHFLAGS?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
