[cctbxbb] Build Notes for cctbx on OS X 10.7.5

James Stroud xtald00d at gmail.com
Thu Mar 21 21:43:10 PDT 2013


Hello All,

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. 

James


====================================
Build Notes for cctbx on OS X 10.7.5
====================================

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.

.. _`Enthought python`: http://www.enthought.com/products/epd.php


1.  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``.

2.  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++

3.  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.

4.  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"]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20130321/1f4299fa/attachment-0002.htm>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20130321/1f4299fa/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20130321/1f4299fa/attachment-0003.htm>


More information about the cctbxbb mailing list