[Python-Dev] build from source on mac uses clang, python.org binary uses gcc (original) (raw)

Ned Deily nad at acm.org
Thu Feb 14 22:33:35 CET 2013

In article <511D350B.1080502 at simplistix.co.uk>, Chris Withers <chris at simplistix.co.uk> wrote:

On 14/02/2013 12:15, Ronald Oussoren wrote: > >> buzzkill:virtualenvs chris$ /src/Python-3.3.0/python.exe >> Python 3.3.0 (default, Jan 23 2013, 09:56:03) >> [GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211.12)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >>>>> >> >> ...which makes lxml pretty unhappy. > > Why is that?

I'm not lxml's maintainer, I'd suggest asking Stefan... > The binary was created on an older release of OSX where gcc is a valid > compiler choice. Distutils > should still pick clang when it detects that gcc is actually llvm-gcc > though, doesn't it do that on your system? No. The gcc-based Python 3.3.0 from python.org uses gcc to compile lxml.

Hmm, that's odd. It should be using clang unless on 10.7 with a current Xcode 4 installed unless something is overriding the compiler selection, e.g. setting CC=clang. (Also, I note you appear to be using an out-of-date clang; Xcode 4.6 and its Command Line Tools are current: $ clang --version Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn Because of the relative newness of clang in the OS X world, it's important to keep up-to-date.)

But, installing lxml 3.1.0 (from the tarball you cite) with the Python 3.3.0 64-bit/32-b it install seems to work fine for me. At least, it didn't get any import errors.

Looking at your traceback (from https://mailman-mail5.webfaction.com/pipermail/lxml/2013-February/006730. html) appears to show that the lxml is picking up libxml2 and libxslt from /Library/Frameworks/Python.framework/Versions/7.2/lib and or /Library/Frameworks/Python.framework/Versions/7.2/lib. That almost certainly is the root of your problems. I'm not sure what those are but possibly EPD Python distributions. Your 3.3 builds should not be trying to used them to satisfy libraries. Perhaps there are links in /usr/local/*. Removing those links or files in /usr/local should allow you to build lxml with the Apple-supplied libxml2 and libxslt. If you want newer versions or the libs, either build them for 64-/32-bit archs or use a third-party package manager like Homebrew or MacPorts to supply them (and/or supply a Python 3.3).

-- Ned Deily, nad at acm.org

More information about the Python-Dev mailing list