I tried to build boost on our cray XT5. It does not support shared libraries, so everything must be static.

I had trouble with 3 files in particular

 

File : libs/test/test/CMakeLists.txt

this has many lines with

boost_test_run(test_case_template_test DEPENDS boost_unit_test_framework SHARED)

which specify to link against the shared library, but there are no checks that shared build is off, there needs to be some kind of IF(SHARED) check around them (unless the shared ref is unnecessary)

 

File : boost/tr1/detail/config_all.hpp

the #define macro for

#        define BOOST_TR1_STD_HEADER(name) <../__GNUC__.__GNUC_MINOR__.__GNUC_PATCHLEVEL__/name>

doesn’t work for me, I removed the “GNUC__.__GNUC_MINOR__.__GNUC_PATCHLEVEL__/” and left only “name”, which then worked.

 

File : libs/graph_parallel/src/mpi_process_group.cpp

needs

#include <cstdio>

 

I had some compile errors using gcc4.4.1 which went away when I switched to 4.3.3, so to get a 100% build I did a make once, switched compilers and make again (using 4.3.3 first gives different errors which go away when you switch to 4.4.1 – templates – they make life fun!).

 

Tests are running now and should appear on the dashboard soon.

 

JB

 

 

 

 

 

From: boost-cmake-bounces@lists.boost.org [mailto:boost-cmake-bounces@lists.boost.org] On Behalf Of Denis Arnaud
Sent: 27 January 2010 18:31
To: Discussion of the CMake-based build system for Boost
Subject: [Boost-cmake] When will the CMake contributions make their way to Boost upstream?

 

Dear All,

 

first, some good news: the packaging of Boost for Fedora/RedHat with CMake has been officially approved (https://fedoraproject.org/wiki/Features/F13Boost141 and  https://fedorahosted.org/fesco/ticket/317) by the Fedora steering comity (FESCo) yesterday :)

 

1. Also, they would like some more information on how and when the Boost-CMake effort will be incorporated within upstream Boost. Would anyone know more about that?

 

2. A new bug has just been opened on the Boost.MPI (and Boost.Graph, depending on MPI as well) packaging part: https://bugzilla.redhat.com/show_bug.cgi?id=559009. I still foresee two non-blocking issues:

2.1. The ability of Boost.MPI (and Boost.Graph) to build with OpenMPI without manually hard-coding the path to OpenMPI (http://lists.boost.org/boost-cmake/2009/12/0861.php).

2.2. The undefined symbols in the Boost.MPI Python module (mpi.so library: http://lists.boost.org/boost-cmake/2009/11/0752.php).

 

Any comment, update, feedback would be welcome.

 

Thanks in advance

 

Best Regards

 

D