Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly

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 mpi.so library linked with the boost_mpi.so library.

The following shows what I get with "make VERBOSE=1":
 Linking CXX shared module ../../../lib/mpi.so
 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
--verbose=1
 /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,mpi.so *-o
../../../lib/mpi.so*CMakeFiles/mpi-mt-shared.dir/python/collectives.cpp.o
[...]
CMakeFiles/mpi-mt-shared.dir/python/py_timer.cpp.o
/usr/lib64/python2.6/config/*libpython2.6.so* -lpthread -lrt *
../../../lib/libboost_python-mt.so.5*

So, obviously, mpi.so is linked with the Python (libpython2.6.so in my case)
and Boost.Python (libboost_python-mt.so.5) libraries, but *not* with the
boost_mpi.so 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/mpi.so
        *libpython2.6.so.1.0* => /usr/lib64/libpython2.6.so.1.0
(0x00007fd9e7eba000)
        [snip]
        *libboost_python-mt.so.5* => /usr/lib64/libboost_python-mt.so.5
(0x00007fd9e7845000)

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

 > 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, __init__.py
> 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 mpi.so library correctly
linked with boost_mpi will be enough. For the rest (__init__.py, 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).

D.