[Pkg-scicomp-devel] Bug#563705: MPI implementations in squeeze

[Adam C Powell IV]

tags 563705 +patch
thanks

Hi and apologies for the long delay...

On Fri, 2010-02-26 at 14:55 -0500, Adam C Powell IV wrote:
> On Fri, 2010-02-26 at 20:22 +0100, Lucas Nussbaum wrote:
> > 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.
> 
> Will do, thanks.  I'll also need to patch (at least my) packages which
> use this, will get to that in short order.

"Short order" turned out to be somewhat long order, but here are the
patches for mpich2 and openmpi.

-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: mpich2-fort-lib-symlinks.patch
Type: text/x-patch
Size: 1230 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/attachments/20100316/47a1a5a4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openmpi-fort-lib-symlinks.patch
Type: text/x-patch
Size: 1232 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/attachments/20100316/47a1a5a4/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/attachments/20100316/47a1a5a4/attachment.pgp>