python - xcrun/lipo freezes with OS X Mavericks and XCode 4.x

Question

Been trying to install psycopg2 with either easy_install or pip, and the terminal gets stuck in a loop between xcrun and lipo.

sidwyn$ sudo easy_install psycopg2
Searching for psycopg2
Reading https://pypi.python.org/simple/psycopg2/
Reading http://initd.org/psycopg/
Reading http://initd.org/projects/psycopg2
Best match: psycopg2 2.5.1
Downloading https://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.5.1.tar.gz#md5=1b433f83d50d1bc61e09026e906d84c7
Processing psycopg2-2.5.1.tar.gz
Writing /tmp/easy_install-dTk7cd/psycopg2-2.5.1/setup.cfg
Running psycopg2-2.5.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-dTk7cd/psycopg2-2.5.1/egg-dist-tmp-4jaXas
clang: warning: argument unused during compilation: '-mno-fused-madd'

It bounces between xcrun and lipo and is stuck forever in this loop. Would appreciate some insights on this.

I'm on OS X Mavericks 10.9, latest build.

Answer 1

A more appropriate fix is:

ln /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/lipo /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo
xcrun -k lipo

Why: xfx's fix will likely break being able to use xcode-select to choose your toolchain in future versions of Xcode.

Pre- Mavericks and Xcode 5.x, /usr/bin/lipo seems to be the actual location of the actual lipo tool (try cat /usr/bin/lipo - looks like a big binary). In Mavericks / Xcode 5.x, lipo was moved to XcodeDefault.xctoolchain, and the binary at /usr/bin/lipo is a thin wrapper that appears to just call xcrun lipo (see nm /usr/bin/lipo), which in turn finds the location of lipo based on xcode-select.

Probably, new versions of xcode-select and/or Mavericks replace /usr/bin/lipo with the wrapper version. If you then try to use lipo with the 4.x toolchain xcode-select'd, it won't work, since the tool isn't contained in older versions of Xcode. Luckily, it's still included in iPhoneOS.platform for some reason, else you'd probably have to pull it from an uncorrupted <=10.8 machine.

It looks as if there was a lot of shuffling of tools between Developer/usr/bin and Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin in the 4->5 switch - it wouldn't surprise me if there were similar problems with other less-often-used command line tools as well.

Finally, the fact that xcrun hangs when it can't find a tool seems like an apple bug, plain and simple.