[pkg-boost-devel] MPI issue on sparc ? Boost::mpi looks for OpenMPI but it should be LAM no ?

[Adam C Powell IV]

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).
> 
> 
>   Selection    Path                      Priority   Status
> ------------------------------------------------------------
> * 0            /usr/lib/openmpi/include   40        auto mode
>   1            /usr/include/lam           30        manual mode
>   2            /usr/lib/mpich/include     10        manual mode
>   3            /usr/lib/openmpi/include   40        manual mode
> 
> 
> 
> On Wed, Jun 9, 2010 at 8:53 PM, Christophe Prud'homme
> <prudhomm at 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
>         <hazelsct at 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20100611/514ee1a2/attachment.pgp>