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. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part