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. 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?