Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
If mpi-default-dev points to lam, then why is OpenMPI installed in the system? Just use mpi-default-dev and libhdf5-mpi-dev and they should be consistent. If they're not, then HDF5 needs a bin NMU. Likewise with boost, that should be built using mpi-default-dev, right? Are you suggesting that mpi-default-dev should conflict with every non-default mpi-dev package on a given architecture, to make certain that nobody has it installed when building such packages? [Separate issue: if there's openmpi on Sparc, why is it not the mpi-default?] -Adam On Thu, 2010-06-10 at 07:02 +0200, Christophe Prud'homme wrote: All, if openmpi is installed on sparc, it takes priority over lam ! (it has priority 40 and lam 30) here is the result of mpic++ -showme:compile on smetana.debian.org -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread and link mpic++ -showme:link -pthread -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl so even though mpi-default-dev point to lam, if openmpi gets also installed it is in practice the default implementation on sparc ! To my opinion this is a bug in the mpi system. Adam ? Others ? There are 3 choices for the alternative mpi (providing /usr/include/mpi). SelectionPath Priority Status * 0/usr/lib/openmpi/include 40auto mode 1/usr/include/lam 30manual mode 2/usr/lib/mpich/include 10manual mode 3/usr/lib/openmpi/include 40manual mode On Wed, Jun 9, 2010 at 8:53 PM, Christophe Prud'homme prudh...@debian.org wrote: I tried, without success so far, to help cmake(FindMPI.cmake) find the proper mpi implementation. It still finds openmpi which breaks linkage with boost::mpi Best regards C. On Wed, Jun 9, 2010 at 12:08 PM, Adam C Powell IV hazel...@debian.org wrote: On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote: On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? Indeed, that's the idea: Build-Depend on libhdf5-mpi-dev and mpi-default-dev and you should have a consistent MPI implementation across both. That said, the LAM HDF5 implementation seems to be missing a couple of libraries, such that for example PETSc doesn't build on architectures where LAM is the default. I disabled PETSc HDF5 support on those arches, but haven't investigated further. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
Hi Adam, thanks for your answer ! On Fri, Jun 11, 2010 at 8:05 PM, Adam C Powell IV hazel...@debian.orgwrote: If mpi-default-dev points to lam, then why is OpenMPI installed in the system? Just use mpi-default-dev and libhdf5-mpi-dev and they should be consistent. If they're not, then HDF5 needs a bin NMU. I am not depending on hdf5, it gets installed due to another build-depends (I am not sure which one) I of course use mpi-default-dev which points to lam unfortunately openmpi gets installed too and has higher priority than lam and all the defaults point to openm pi mpic++, incluce, libs... Likewise with boost, that should be built using mpi-default-dev, right? boost is also build-depending on mpi-default-dev I believe neither life or boost are at fault but rather mpi-default* which has an inconsistent behavior on sparc Are you suggesting that mpi-default-dev should conflict with every non-default mpi-dev package on a given architecture, to make certain that nobody has it installed when building such packages? no I suggest that if lam is the default implementation then it should be the default if openmpi is installed it becomes the default log on smetana.debian.org and do ' dchroot unstable' and check for yourself. [Separate issue: if there's openmpi on Sparc, why is it not the mpi-default?] good question. I fixed the problem by enforcing lam I set the MPI_COMPILER to mpic++.lam explicitely rather than mpic++ which points to the openmpi one also there is a mpicxx for openmpi but none for lam . So the alternatives are not consistent should I fill a bug on mpi-default* ? Best regards C.
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
Hi Christophe, On Fri, 2010-06-11 at 23:48 +0200, Christophe Prud'homme wrote: Hi Adam, thanks for your answer ! On Fri, Jun 11, 2010 at 8:05 PM, Adam C Powell IV hazel...@debian.org wrote: If mpi-default-dev points to lam, then why is OpenMPI installed in the system? Just use mpi-default-dev and libhdf5-mpi-dev and they should be consistent. If they're not, then HDF5 needs a bin NMU. I am not depending on hdf5, it gets installed due to another build-depends (I am not sure which one) It sounds like the bug is here. When this is found and fixed, everything should work with the MPI defaults. I of course use mpi-default-dev which points to lam unfortunately openmpi gets installed too and has higher priority than lam and all the defaults point to openm pi mpic++, incluce, libs... Likewise with boost, that should be built using mpi-default-dev, right? boost is also build-depending on mpi-default-dev I believe neither life or boost are at fault but rather mpi-default* which has an inconsistent behavior on sparc Are you suggesting that mpi-default-dev should conflict with every non-default mpi-dev package on a given architecture, to make certain that nobody has it installed when building such packages? no I suggest that if lam is the default implementation then it should be the default if openmpi is installed it becomes the default log on smetana.debian.org and do ' dchroot unstable' and check for yourself. I believe you. But the alternatives mechanism isn't going to work in this way, so we'd need some other way to create the default links. [Separate issue: if there's openmpi on Sparc, why is it not the mpi-default?] good question. Here's bug #2. The mpi-defaults package is only there to provide LAM as a backup to openmpi on the arches where it doesn't work. Where it works, it should be the default. I fixed the problem by enforcing lam I set the MPI_COMPILER to mpic++.lam explicitely rather than mpic++ which points to the openmpi one also there is a mpicxx for openmpi but none for lam . So the alternatives are not consistent should I fill a bug on mpi-default* ? I don't think it needs a separate mpicxx, that's just the openmpi name for the same thing (they point to the same binary in openmpi). IIRC mpic++ should be a link pointing to the default implementation, is that not the case? I don't have time to file these bugs now, but will try to get to it over the weekend. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote: On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? Indeed, that's the idea: Build-Depend on libhdf5-mpi-dev and mpi-default-dev and you should have a consistent MPI implementation across both. That said, the LAM HDF5 implementation seems to be missing a couple of libraries, such that for example PETSc doesn't build on architectures where LAM is the default. I disabled PETSc HDF5 support on those arches, but haven't investigated further. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
I tried, without success so far, to help cmake(FindMPI.cmake) find the proper mpi implementation. It still finds openmpi which breaks linkage with boost::mpi Best regards C. On Wed, Jun 9, 2010 at 12:08 PM, Adam C Powell IV hazel...@debian.orgwrote: On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote: On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? Indeed, that's the idea: Build-Depend on libhdf5-mpi-dev and mpi-default-dev and you should have a consistent MPI implementation across both. That said, the LAM HDF5 implementation seems to be missing a couple of libraries, such that for example PETSc doesn't build on architectures where LAM is the default. I disabled PETSc HDF5 support on those arches, but haven't investigated further. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
All, if openmpi is installed on sparc, it takes priority over lam ! (it has priority 40 and lam 30) here is the result of mpic++ -showme:compile on smetana.debian.org -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread and link mpic++ -showme:link -pthread -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl so even though mpi-default-dev point to lam, if openmpi gets also installed it is in practice the default implementation on sparc ! To my opinion this is a bug in the mpi system. Adam ? Others ? There are 3 choices for the alternative mpi (providing /usr/include/mpi). SelectionPath Priority Status * 0/usr/lib/openmpi/include 40auto mode 1/usr/include/lam 30manual mode 2/usr/lib/mpich/include 10manual mode 3/usr/lib/openmpi/include 40manual mode On Wed, Jun 9, 2010 at 8:53 PM, Christophe Prud'homme prudh...@debian.orgwrote: I tried, without success so far, to help cmake(FindMPI.cmake) find the proper mpi implementation. It still finds openmpi which breaks linkage with boost::mpi Best regards C. On Wed, Jun 9, 2010 at 12:08 PM, Adam C Powell IV hazel...@debian.orgwrote: On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote: On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? Indeed, that's the idea: Build-Depend on libhdf5-mpi-dev and mpi-default-dev and you should have a consistent MPI implementation across both. That said, the LAM HDF5 implementation seems to be missing a couple of libraries, such that for example PETSc doesn't build on architectures where LAM is the default. I disabled PETSc HDF5 support on those arches, but haven't investigated further. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
Steve, On Mon, Jun 7, 2010 at 5:43 AM, Steve M. Robbins st...@sumost.ca wrote: The mpi-defaults control file specifies lam for sparc, check the buildd log: https://buildd.debian.org/fetch.cgi?pkg=mpi-defaultsarch=sparcver=0.6stamp=1246463638file=logas=raw As far as I can tell, Boost is consistent. The problem lies elsewhere. I think that's exactely where the problem is but the issue is not with boost::mpi but with the mixup between lam and openmpi packages! somehow life picks openmpi and compiles some boost::mpi function with it whereas boost::mpi was compiled with lam hence the linkage problems. Lam is the default on sparc but somehow cmake script FindMPI.cmake picked openmpi - Found MPI: /usr/lib/openmpi/lib/libmpi_cxx.so here is where FindMPI looks for mpi set(_MPI_PACKAGE_DIR mpi mpich openmpi lib/mpi lib/mpich lib/openmpi MPICH/SDK Microsoft Compute Cluster Pack ) If you look here https://buildd.debian.org/fetch.cgi?pkg=lifearch=sparcver=0.9.24-4stamp=1275756138file=logas=raw it installs lam and openmpi and some packages like hdf5 are specifically installed with openmpi support. On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? I found this in FindMPI.cmake # If CMake initially finds a different MPI than was intended, and you # want to use the MPI compiler auto-detection for a different MPI # implementation, set MPI_COMPILER to the MPI compiler driver you want # to use (e.g., mpicxx) and then set MPI_LIBRARY to the string # MPI_LIBRARY-NOTFOUND. When you re-configure, auto-detection of MPI # will run again with the newly-specified MPI_COMPILER. I will try that ASAP. Best regards C.
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud'homme wrote: On my side life depends solely on mpi-default-dev, it seems that some other package don't (e.g. hdf5), isn't it a problem ? Yes, something like that is likely the problem. Note that libhdf5-mpi-dev is supposed to alleviate that problem as it depends on the default MPI version. Installing that package should not pull in any non-default MPI packages, IMHO. Adam: any comment? If you can't avoid having multiple MPI implementations installed, the file /usr/share/mpi-default-dev/debian_defaults might be useful in configuration CMake correctly. Good luck, -Steve signature.asc Description: Digital signature
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
1. http://packages.qa.debian.org/l/life.html http://packages.qa.debian.org/l/life.html 2. https://buildd.debian.org/status/package.php?p=life#fail-life-sparc On Sun, Jun 6, 2010 at 9:36 AM, Christophe Prud'homme prudh...@debian.orgwrote: All, for the last few weeks, I have life [1] failing to compile on sparc (see below). Boost::MPI looks for OpenMPI but I was told that that the MPI implementation on sparc is LAM (is that right?) Life and Boost::Mpi use mpi-default-dev in Build-Depends . It seems like there is something fishy with MPI on sparc or am I missing something ? thank you very much in advance for your help Best regards C. CMakeFiles/life_doc_bratu.dir/bratu.cpp.o: In function `void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)': bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x11c): undefined reference to `boost::mpi::detail::packed_archive_recv(ompi_communicator_t*, int, int, boost::mpi::packed_iarchive, ompi_status_public_t)' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x24c): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x268): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x27c): undefined reference to `boost::mpi::detail::packed_archive_recv(ompi_communicator_t*, int, int, boost::mpi::packed_iarchive, ompi_status_public_t)' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x39c): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x404): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x414): undefined reference to `boost::mpi::detail::packed_archive_send(ompi_communicator_t*, int, int, boost::mpi::packed_oarchive const)' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x4c8): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const'
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
All, I think the problemI mention below with respect to boost::mpi, openmpi and life on sparc is the following: - boost::mpi was compiled with lam on sparc - openmpi is available on sparc and is the default implementation thanks to mpi-default-dev - life build-depends on mpi-default-dev (and hence openmpi). When life is being compiled it instantiates the boost::mpi object with openmpi (instead of lam) and at link time, the linker fails to find the boost::mpi symbols compiled with openmpi. I will submit a bug on boost/boost::mpi in the next few days unless an upload fixes this in the mean time Best regards C. On Sun, Jun 6, 2010 at 9:37 AM, Christophe Prud'homme prudh...@debian.orgwrote: 1. http://packages.qa.debian.org/l/life.html http://packages.qa.debian.org/l/life.html 2. https://buildd.debian.org/status/package.php?p=life#fail-life-sparc On Sun, Jun 6, 2010 at 9:36 AM, Christophe Prud'homme prudh...@debian.org wrote: All, for the last few weeks, I have life [1] failing to compile on sparc (see below). Boost::MPI looks for OpenMPI but I was told that that the MPI implementation on sparc is LAM (is that right?) Life and Boost::Mpi use mpi-default-dev in Build-Depends . It seems like there is something fishy with MPI on sparc or am I missing something ? thank you very much in advance for your help Best regards C. CMakeFiles/life_doc_bratu.dir/bratu.cpp.o: In function `void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)': bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x11c): undefined reference to `boost::mpi::detail::packed_archive_recv(ompi_communicator_t*, int, int, boost::mpi::packed_iarchive, ompi_status_public_t)' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x24c): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x268): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x27c): undefined reference to `boost::mpi::detail::packed_archive_recv(ompi_communicator_t*, int, int, boost::mpi::packed_iarchive, ompi_status_public_t)' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x39c): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x404): undefined reference to `boost::mpi::communicator::operator ompi_communicator_t*() const' bratu.cpp:(.text._ZN5boost3mpi10all_reduceISt6vectorIiSaIiEEN4Life6detail11vector_plusIivRKNS0_12communicatorERKT_RSC_T0_[void boost::mpi::all_reducestd::vectorint, std::allocatorint , Life::detail::vector_plusint (boost::mpi::communicator const, std::vectorint, std::allocatorint const, std::vectorint, std::allocatorint , Life::detail::vector_plusint)]+0x414):
Re: MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?
On Sun, Jun 06, 2010 at 08:10:41PM +0200, Christophe Prud'homme wrote: All, I think the problemI mention below with respect to boost::mpi, openmpi and life on sparc is the following: - boost::mpi was compiled with lam on sparc Boost builds with mpi-default-dev. - openmpi is available on sparc and is the default implementation thanks to mpi-default-dev The mpi-defaults control file specifies lam for sparc, check the buildd log: https://buildd.debian.org/fetch.cgi?pkg=mpi-defaultsarch=sparcver=0.6stamp=1246463638file=logas=raw As far as I can tell, Boost is consistent. The problem lies elsewhere. -Steve signature.asc Description: Digital signature
