These notes describe a successful build of cctbx against a specific python interpreter, namely Enthought python 7.3-2 for x86_64.
Although working, versions of cctbx are available for both the system python or with a dedicated python, these canned solutions are not optimal. First, it's not advisable to modify system utilities. Although cctbx seems well-behaved in this regard, other packages may not be so well behaved. Second, the canned approach requires building many of the numerous packages that come with bundeld python distributions like the Enthought distribution (some such packages exceed even cctbx in their difficulty to build). Third, if every package required its own python, every script would need to fire-up dozens of separate interpreters just to do its job, resulting in significant computational overhead with consummately slower execution times.
The default c++ compiler for OS X 10.7 is actually clang (/usr/bin/c++). Using clang exposes invalid template code. The first of many errors is:
In file included from
/opt/cctbx/cctbx_sources/mmtbx/bulk_solvent/bulk_solvent_ext.cpp:7:
/opt/cctbx/cctbx_sources/mmtbx/bulk_solvent/bulk_solvent.h:496:21:
error: call to function 'r_factor' that is neither visible in the template
definition nor found by argument-dependent lookup
r.push_back(r_factor(f_obs, f_model.const_ref()));
These types of errors are documented at the page http://clang.llvm.org/compatibility.html#dep_lookup
Note
The installation directory is /opt/cctbx.
I tried to use the HPC compilers at http://hpc.sourceforge.net/, but they do not recognize the -no-cpp-precomp flag. The web page https://svn.boost.org/trac/boost/ticket/6697 suggests the problem is with boost. However, according to the comments therein, this should have been fixed in boost 1.50. I am building against boost 1.52. Perplexed about the source of this compiler flag, I tracked it down to the file cctbx_sources/libtbx/SConscript, after spending much of a day learning how scons goes about its business. There are two possible fixes:
Comment the following line in cctbx_sources/libtbx/SConscript:
# env_etc.ccflags_base.extend(["-no-cpp-precomp"])
Link /usr/bin/g++ to c++ in a way that it will be found first in the path. For example:
% ln -s /usr/bin/g++ ${HOME}/bin/c++
I first fixed the -no-cpp-precomp error by the former, commenting the offending line in cctbx_sources/libtbx/SConscript but this failed with the error:
/opt/cctbx/cctbx_sources/scitbx/array_family/memory.h:35:47:
error: operator '&&' has no right operand
#elif defined(_XOPEN_SOURCE) && _XOPEN_SOURCE >= 600 && defined(_POSIX_ADVISORY_INFO)
^
The page http://forums.fedoraforum.org/archive/index.php/t-52929.html suggests that the naked _XOPEN_SOURCE wrecks the conditional when _XOPEN_SOURCE is not defined. One possible way to overcome this problem is to change the offending line into a nested if/then, hoping that the comparison never gets evaluated under circumstances when _XOPEN_SOURCE is not defined:
#elif defined(_XOPEN_SOURCE) #if _XOPEN_SOURCE >= 600 && defined(_POSIX_ADVISORY_INFO) #define SCITBX_AF_HAS_ALIGNED_MALLOC 1 #define SCITBX_AF_USE_POSIX_FOR_ALIGNED_MALLOC 1 #endif #endif
However, this was unnecessary because the second fix to the -no-cpp-precomp error (linking /usr/bin/g++ to c++) worked and avoided changing the preprocessor source.
Left to its own devices, scons could not find my fftw3.h, which I have installed (via fink) to /sw/include/fftw3.h. To fix this problem, I inserted the second of the following two lines into the file cctbx_sources/libtbx/SConscript:
env_etc.ccflags_base.extend(["-no-cpp-precomp"]) env_etc.ccflags_base.extend(["-I/sw/include"])
Although this allowed scons to find the header, it could not find the actual library, requiring the insertion of the second of the following lines into the file cctbx_sources/libtbx/SConscript:
env_etc.shlinkflags_bpl = [ "-L/sw/lib", "-w", # suppress "source/lib does not exist" warning "-bundle", "-undefined", "dynamic_lookup"]