2009/12/22 Troy D. Straszheim <t...@resophonic.com>
> 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.
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
