Update:
My former answer has mostly become obsolete as of Mesos 0.17.0 due to the fact that this version does fully handle clang compilage (Yay!). So there is no need to compile it using gcc anymore - just go ahead and use Xcode's clang (Xcode commandline utilities).
In case you still get into trouble getting the Python bindings to work, please add a comment or new question here on StackOverflow or post into the Mesos Mailing list.
Mesos version 0.16.0 or lower:
How to fix the Python bindings of Mesos on OS X (10.9).
Install Python 2.7.3 via homebrew
Find out which versions are available
brew versions python
2.7.6 git checkout 3c86d2b /usr/local/Library/Formula/python.rb
2.7.5 git checkout a04b443 /usr/local/Library/Formula/python.rb
2.7.3 git checkout 865f763 /usr/local/Library/Formula/python.rb
2.7.4 git checkout 280581d /usr/local/Library/Formula/python.rb
[...]
Select Python 2.7.3
cd /usr/local/Library/Formula/
git checkout 865f763 /usr/local/Library/Formula/python.rb
brew install python
Make sure you do not force installing a universal build (32 + 64bit) as that would again cause the same issue explained below. The default is 64bit only and that is just fine.
Rebuild Mesos in connection with your custom Python installation
rm -rf build
rm -rf ~/.python-eggs
mkdir build
cd build
../configure CXX=g++-4.7 CC=gcc-4.7 PYTHON=/usr/local/bin/python
make
make check
You should now see a properly functioning test, hence a perfectly fine Mesos Python binding:
[ RUN ] ExamplesTest.PythonFramework
[ OK ] ExamplesTest.PythonFramework (1682 ms)
As asking users to install a custom Python version often is just wrong but in this case appears to be inevitable, let me draft an explanation of the issue. And maybe one of the readers knows a better workaround.
Manually executing that test using the verbosive output setting does help identifying the exact problem.
bin/mesos-tests.sh --gtest_filter="*.PythonFramework" --verbose
Traceback (most recent call last): File
"/Users/till/Documents/Development/github/mesos-master/build/../src/examples/python/test_framework.py",
line 23, in
import mesos File "build/bdist.macosx-10.9-intel/egg/mesos.py", line 26, in File
"build/bdist.macosx-10.9-intel/egg/_mesos.py", line 7, in
File "build/bdist.macosx-10.9-intel/egg/_mesos.py", line 6, in
bootstrap ImportError: dlopen(/Users/till/.python-eggs/mesos-0.16.0-py2.7-macosx-10.9-intel.egg-tmp/_mesos.so,
2): Symbol not found: __ZNSoD0Ev Referenced from:
/Users/till/.python-eggs/mesos-0.16.0-py2.7-macosx-10.9-intel.egg-tmp/_mesos.so
Expected in: flat namespace in
/Users/till/.python-eggs/mesos-0.16.0-py2.7-macosx-10.9-intel.egg-tmp/_mesos.so
The important detail is the fact that the dynamic linkage of that native Python egg failed.
The reasoning is to be found within the distutils build step of this module when building mesos 0.16. The Python distutils derive their build-settings directly from python-config. As your Python was built using clang, the distutils will try to build your native egg using clang as well.
Issues:
- Mesos' autoconf phase did not propagate the compiler settings into the
distutils build phase. So even though Mesos itself is being built using gcc-4.7 in the above description, the egg is being built using clang. The result is a mishmash of libc++ and stdlibc++ which are not ABI compatible.
- that part is being fixed right now, Mesos will use the same compiler in the
distutils build phase as well (see MESOS-798 and MESOS-799). Chances are pretty high that when you read this answer, that particular issue was already taken care of.
- The default OS X Python
distutils do enforce building universal binaries (i386 + x86_64) using parameters that only the gcc-frontend of clang supports. There appears to be no workaround, hence all dynamically linked dependencies of that egg will have to be built for both architectures as well (this appears to be a leftover from OS X 10.6).
- Mesos itself is linked statically into that egg, hence it does not have to be built as a universal binary for the egg to build and function on a 64bit platform. It will however fail to execute on a 32bit platform.
- As long as Mesos does not support clang compilage (hence being linked against libc++), the only proper workaround seems to be to install a differently compiled Python. A quick and easy solution is using
homebrew to install Python 2.7.3. Note: do not install Python 2.7.6 (the current default of homebrew) as that one has issues in connection with its autoconf developer macro (see MESOS-617)
