Boost.MPI - compilation problems

Hi, I seem to be having similar problems to this post: http://lists.boost.org/boost-users/2007/10/31648.php My MPI implementation is MPICH2; the first example in the docs at http://www.osl.iu.edu/~dgregor/boost.mpi/doc/mpi/tutorial.html works fine (this just creates a communicator and prints each process' rank). The second example in the tutorial (with recv and send): #include <boost/mpi.hpp> #include <iostream> #include <boost/serialization/string.hpp> namespace mpi = boost::mpi; int main(int argc, char* argv[]) { mpi::environment env(argc, argv); mpi::communicator world; if (world.rank() == 0) { world.send(1, 0, std::string("Hello")); std::string msg; world.recv(1, 1, msg); std::cout << msg << "!" << std::endl; } else { std::string msg; world.recv(0, 0, msg); std::cout << msg << ", "; std::cout.flush(); world.send(0, 1, std::string("world")); } return 0; } fails to link: output on g++ 4.0.1 on OSX 10.5 is Undefined symbols: "boost::mpi::communicator::operator int() const", referenced from: boost::mpi::status boost::mpi::communicator::recv_impl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(int, int, std::basic_string<char, std::char_traits<char>, std::allocator<char>
&, mpl_::bool_<false>) constin ccxddhyu.o void boost::mpi::communicator::send_impl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(int, int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, mpl_::bool_<false>) constin ccxddhyu.o ld: symbol(s) not found
My compiled invocation (which as mentioned compiles the first tutorial example) is just mpic++ -lboost_mpi-mt -lboost_serialization-mt main.cpp The problem (as for the person in the post I linked at the top) seems to be that mpi::communicator defines a conversion operator to MPI_Comm, which is just a typedef for int in MPICH2, but somehow the correct operator isn't found in the compiled lib.. Unlike the person in the linked post, I haven't had any other MPI libraries installed before, so there should be no inconsistencies. This problem occurs with 32 and 64-bit compiled libs built from subversion repos. code today. Thanks Tom
participants (1)
-
Tom Smith