问题
I'm trying to use distutils to compile a cython module using Enthought Canopy's version of python; however it's clear there is a mixup between gcc and clang. Distutils is trying to compile the module using gcc and the clang option -arch x86_64. The problem is that I have gcc installed from macports, so gcc isn't just a link to clang. I can get the module to compile using CC='clang' ./setup.py build_ext, but this feels a little hacky in terms of distributing the module. Is there something I can put in setup.py to make it more robust with this sort of setup? I'm thinking something along the lines of using clang if -arch is in the compiler flags, but I can't seem to find where exactly distutils gets the compiler flags, or how to tell it to use a specific compiler.
回答1:
Distutils is trying to compile the module using gcc and the clang option -arch x86_64.
That's not a clang option; it was in gcc for years before clang existed.
The problem is that I have gcc installed from macports, so gcc isn't just a link to clang.
gcc is never just a link to clang, unless you've really done something weird on your Mac. In particular, if you've install the Xcode Command Line Tools necessary to include MacPorts, you will have a /usr/bin/gcc that's a link to gcc-4.2 or llvm-gcc-4.2 (or gcc-4.0 or older). One day soon, Apple will drop support for llvm-gcc, and there will be nothing called gcc at all.**
I can get the module to compile using CC='clang' ./setup.py build_ext, but this feels a little hacky in terms of distributing the module
The module apparently wants to build with gcc, by which it means Apple's /usr/bin/gcc.
Relying on gcc to be any specific compiler is almost always a bad idea, as the MacPorts documentation explains.
However, in this case, it makes sense for Python to do this. Python remembers the compiler used to build it, and the same compiler settings, and so on, so it can be sure that distutils will build modules it can actually use. So, if it was built with /usr/bin/gcc, with -arch x86_64, that's what it's going to try to use to build modules. You can run the python-config tool (each of your Python installations will have its own, so make sure you run the right one) to see exactly what it wants.
You can almost always get away with substituting Apple's clang for Apple's gcc-4.2. But substituting some other random compiler that doesn't even support the same options? That's not going to work.
If you want to build Python modules with MacPorts, you almost certainly want to build Python itself with MacPorts, not use some precompiled binary installer. On top of that, you probably want to use ports for any Python modules that have them, instead of building them manually, because many of them require workarounds to work with MacPorts.
On the other hand, if you plan to build non-MacPorts software—Python modules or otherwise—you're really better off not putting the MacPorts gcc as the top thing on the PATH. Almost every configure/setup.py/etc. ever written will detect that you're on a Mac, expect gcc to be Apple gcc, and pass -arch flags, and so on. (In fact, you'll notice that even many ports explicitly require apple-gcc-4.2, llvm-gcc-4.2, or clang, because even the MacPorts team couldn't get them working with a different compiler. Are you sure you want to try?)
* … and that will be a link to, say, ../llvm-gcc-4.2/bin/llvm-gcc-4.2, which will itself by a link to or stub wrapper around i686-apple-darwin11-llvm-gcc-4.2… but that's not important.
** Or at least that was true off and on in the Xcode 5.0 betas.
来源：https://stackoverflow.com/questions/18971012/compiling-cython-modules-when-gcc-is-on-the-path-in-osx