Problems building under different OS

I’ll do two posts about two different problems I’m having under MacOS and Ubuntu. First:

Trying to build from PyRosetta.develop@54516 on Mac OS X Lion 10.7.5 with (and linking against) python 2.7.3 installed with homebrew.

Main Problem
The build itself completes (with a couple of exceptions – see end of this post) with errors like this:

darwin.compile.c++ bin.v2/libs/python/build/darwin-4.2.1/release/threading-multi/object/function.o
In file included from /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:126,
from ./boost/python/detail/wrap_python.hpp:142,
from ./boost/python/detail/prefix.hpp:13,
from ./boost/python/object/function.hpp:8,
from ./boost/python/docstring_options.hpp:8,
from libs/python/src/object/function.cpp:6:
/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/include/python2.7/modsupport.h:27: warning: 'PyArg_ParseTuple' is an unrecognized format function type

But importing anything from rosetta causes immediate segfault. By strategically commenting out lines in __init__.py files and in _all_at_once.?.cpp files, then recompiling and re-linking (by hand, copying the relevant commands from output of BuildBindings.py) just those all_at_once files, I’ve convinced myself that segfaults are caused by attempting to import function definitions with default values assigned to any arguments. Example from basic/gpu/__gpu_all_at_once_.0.cpp:

...
Timer_exposer.def( boost::python::init< ::basic::gpu::Timer const & > ( (boost::python::arg("")) , "basic/gpu/Timer.hh:28" ) );
Timer_exposer.def( boost::python::init< ::basic::Tracer::TracerProxy &, boost::python::optional< char const * > > ( (boost::python::arg("t"), boost::python::arg("tag")=(0)) , "basic/gpu/Timer.hh:38" ) );
Timer_exposer.def( boost::python::init< > () );
...

causes segfault on import, but

...
Timer_exposer.def( boost::python::init< ::basic::gpu::Timer const & > ( (boost::python::arg("")) , "basic/gpu/Timer.hh:28" ) );
// Timer_exposer.def( boost::python::init< ::basic::Tracer::TracerProxy &, boost::python::optional< char const * > > ( (boost::python::arg("t"), boost::python::arg("tag")=(0)) , "basic/gpu/Timer.hh:38" ) );
Timer_exposer.def( boost::python::init< > () );
...

doesn’t. I think this is related to the ‘PyArg_ParseTuple’ warnings during compilation, but I can’t figure out how to fix it. I’ve compiled with the native MacOS gcc (LLVM-gcc), CLang, and gcc-4.7 installed with homebrew. Outcome is the same every time.

Inconvenience issues I encountered along the way

1) Running BuildPyRosetta.sh with -jX, where X>1 caused this error:

Traceback (most recent call last):
File "./BuildBindings.py", line 2112, in
if __name__ == "__main__": main(sys.argv)
File "./BuildBindings.py", line 290, in main
buildModule(n, bindings_path, include_paths=options.I, libpaths=options.L, runtime_libpaths=options.L, gccxml_path=options.gccxml)
File "./BuildBindings.py", line 1009, in buildModule
return buildModule_UsingCppParser(path, dest, include_paths, libpaths, runtime_libpaths, gccxml_path)
File "./BuildBindings.py", line 1632, in buildModule_UsingCppParser
mWait(tag=path) # wait for all compilation jobs to finish...
File "./BuildBindings.py", line 484, in mWait
r = os.waitpid(j.pid, os.WNOHANG)
OSError: [Errno 10] No child processes

where the offending PID was the original call to BuildPyRosetta.sh (I think). I encased r = os.waitpid(j.pid, os.WNOHANG) in a try/except block and the build seemed to go fine. Strangely, this did not happen when building from scratch with DeployPyRosetta.py -jX, X>1.

2) Final linking of _all_at_once_.so libraries failed several times because of functions declared in header files but not defined in .cc files. I think I finally got them all:

core::scoring::methods::PBLifetimeCache::set_pbp
core::scoring::methods::PBLifetimeCache::set_pose
protocols::topology_broker::ConstraintClaimer::set_drop_random_rate(double)


3) This is really minor, but setting the –gccxml-compiler flag didn’t seem to affect what compiler was used, or at least not the output produced by the script. Every time llvm-g++ was used – the default in MacOS.