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