[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> <hazelsct@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.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: