It's pretty typical for ccache packages to install symlinks for compilers that may not be present on the system, such as Homebrew's ccache package.  Unfortunately, the _osx_support.py file is mislead by the presence of the symlink and ends up backtracing.

This issue is present in 2.7 and onwards.  I'm attaching two possible fixes for the problem, both created against 2.7.  The issue is that the symlink in detected, but _read_output() returns None, which then fails when the output is examined (if 'str' in None...).  The first patch does a simple non-empty check.  The alternate version makes _read_output() return an empty string instead of None.

Here's the alternate fix.

New changeset e3217efa6edd by Ned Deily in branch '2.7':
Issue #21311: Avoid exception in _osx_support with non-standard compiler
http://hg.python.org/cpython/rev/e3217efa6edd

New changeset 3d1578c705c9 by Ned Deily in branch '3.4':
Issue #21311: Avoid exception in _osx_support with non-standard compiler
http://hg.python.org/cpython/rev/3d1578c705c9

New changeset 2a4401109672 by Ned Deily in branch 'default':
Issue #21311: merge with 3.4
http://hg.python.org/cpython/rev/2a4401109672

Thanks for the report and the patches.  I am not sure exactly what problem using ccache is causing but it is clear that, if for whatever reason the call to _read_output fails and returns None, the 'llvm-gcc' test will fail so that test should be fixed as suggested in your first patch which I've applied for release in 2.7.7, 3.4.1, and 3.5.0.

Thank you Ned!  The issue is that you can create symlinks to ccache to and put them on your path.  Distros do this for you now, but most create symlinks for a bunch of compilers... including ones that may not be installed.  So the presence of the name ('gcc', for instance) doesn't mean that the compiler is actually installed.  It could be a symlink to the ccache binary and running it could fail.  I hope that makes a little more sense.

Thanks again for applying the patch!