Re: MPI implementations in squeeze
On 26/02/10 at 10:46 -0500, Adam C Powell IV wrote:
> On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote:
> > On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote:
> > > On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote:
> > > > > > There is not much progress so far with respect to changing mpi-defaults
> > > > > > to use MPICH2 instead of LAM on the architectures where Open MPI is not
> > > > > > available yet. This needs a round of binNMUs. Marc Brockschmidt said he
> > > > > > will look at the request to debian-release in the next few days, so this
> > > > > > might resolve soon as well.
> > > > >
> > > > > Something to consider: this will break a lot of packages which use
> > > > > FORTRAN until 563705 is fixed, and then that will require mods to
> > > > > packages.
> > > >
> > > > I understand that bug as:
> > > > if mpich2 or openmpi don't do the right thing when calling
> > > > mpif77/mpif90, then symlinks are needed.
> > > >
> > > > Is there a proof that either of them doesn't do the right thing?
> > > > Wouldn't it be more appropriate to fix them to do the right thing?
> > > >
> > > > (Those are honest questions -- I don't know anything about fortran)
> > >
> > > As discussed before (including in the bug), when there are mixed FORTRAN
> > > and C++ symbols, it's not clear whether to use mpif77/90 or mpic++.
> > >
> > > Also, it's a big convenience: a lot of packages make multiple
> > > executables and/or libraries, some of which use MPI and some don't.
> > > Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib
> > > directories seems easier than telling them to use mpicc and friends for
> > > some targets and gcc for others.
> >
> > I'm not sure I buy that, since mpicc & friends also hide include paths,
> > which are not handled with alternatives currently.
>
> Are you sure?
>
> % update-alternatives --display mpi
> mpi - auto mode
> link currently points to /usr/lib/openmpi/include
> /usr/lib/openmpi/include - priority 40
> slave libmpi++.so: /usr/lib/openmpi/lib/libmpi_cxx.so
> [And a bunch of other slaves]
>
> > It sounds more like a
> > way to break packages by getting them linked with the wrong version of
> > MPI.
> > Do you know of packages doing that already?
>
> I've used this in most of my packages: petsc, hypre, libmesh, the new
> netgen and med-fichier under development (pending togl and updated hdf5
> respectively), and salomé under development.
>
> Why would this break packages, if they just build-depend on
> mpi-default-dev? If the mpicc/mpif77 etc. alternatives work, why not
> the includes and libs as well?
OK. Since it's harmless anyway, could you prepare and test patches for
openmpi and mpich2? Since it would be a slave alternative, it doesn't
require any alternatives transition.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: