Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
From: Denis Arnaud (denis.arnaud_boost_at_[hidden])
Date: 2009-12-22 09:42:13

2009/12/22 Troy D. Straszheim <troy_at_[hidden]>

> What problem are you trying to solve? If you make with VERBOSE=1 I
> believe you will see that boost_mpi is linked already.

I just try to have the library linked with the library.

The following shows what I get with "make VERBOSE=1":
 Linking CXX shared module ../../../lib/
 cd /home/build/dev/packages/BUILD/boost-1.41.0.cmake0/build/libs/mpi/src &&
/usr/bin/cmake -E cmake_link_script CMakeFiles/mpi-mt-shared.dir/link.txt
 /usr/lib64/ccache/c++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-Wl,-z,noexecstack -Wl,-rpath -Wl,/usr/lib64/mpich2 -shared
-Wl,-soname, *-o
/usr/lib64/python2.6/config/** -lpthread -lrt *

So, obviously, is linked with the Python ( in my case)
and Boost.Python ( libraries, but *not* with the library!
[Note that I use a soname version of 5, instead of 1.41.0, for compatibility
with Fedora 12, where Boost has been delivered with a soname version of 5]

Another way to see the same thing:
 $ ldd ../../../build/lib/
        ** => /usr/lib64/
        ** => /usr/lib64/

resulting in a lot of missing symbols, e.g.:
 $ ldd -r ../../../build/lib/ 2>&1 | c++filt | head
 *undefined symbol: typeinfo for boost::mpi::exception

> The other question is: how could we set a distinct installation path for
> that
> > Python extension?
> > We could maybe define a CMAKE_PYTEXT_INSTALL_PREFIX variable for that
> purpose?

> Yes one could. You could pass NO_INSTALL to add_single_library() and
> then call cmake's install() manually on the mpi target. But it'd be
> nice if this were more generally usable. Typically things are more
> complicated, e.g. there is associated pure python code (say,
> and some other stuff) and different modules will want to live in
> different subdirectories of the system's site-packages... should one
> just hand this off to python's distutils? Are there any well-behaved,
> cmake-built python bindings in existence? What do they do?

I'm unfortunately not a Python packaging expert. If time allows, I'll try to
look at a few projects (packaged for Fedora) delivering Python extensions.
But, in the meantime, I guess that delivering the library correctly
linked with boost_mpi will be enough. For the rest (, etc.), I'll
add the needed files manually in the Python site-packages (I speak about the
delivery of Boost by the corresponding RPM package).


Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at