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? And for something like med-fichier, wouldn't "CC=mpicc" and friends unnecessarily link a lot of non-MPI executables and libs to MPI libraries, causing memory bloat? Finally, are you sure "mpif77 c++-object.o c-object.o f77-object.o -o executable" will bring in all of the necessary libraries? I've never tried it, but I'd want to make sure it works for at least OpenMPI and MPICH2 before committing to use it. > > And we have libmpi.so and libmpi++.so symlinks, why not libmpif77.so? :) > > Well, maybe it might be a better idea to drop those links ;) Fair enough. :-) -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