[Copying -beowulf as there's likely some interest there as well.] On Thu, 2008-10-30 at 15:21 +0100, Manuel Prinz wrote: > Am Dienstag, den 21.10.2008, 15:57 -0400 schrieb Adam C Powell IV: > > On Tue, 2008-10-21 at 12:34 -0700, Don Armstrong wrote: > > > The right way to solve this, IMO, is to fix libhdf5 to provide the > > > same API and ABI, possibly in a separate libhdf5 package, which > > > dlopens (or similar) the appropriate -serial/openmpi/mpich adapter > > > bits. > > > > Good luck with that. MPI almost seems designed to be ABI-incompatible. > > That's why there are so many -mpich -lam -openmpi packages around. It's > > a >decade-old problem, and won't be solved any time soon. > > ACK to that. The problem will probably not go away anytime soon. A new > standard seems to be on the way, and I really hope things improve with > it. Wow, that would be great! Do you have a link where I can learn more? > > One solution is to standardize around the "latest and greatest". With a > > lot of old MPI implementations merging and steering their development > > effort into OpenMPI, that seems to be a leader in this regard. But it's > > not on all of Debian's platforms, see Bug 376833. So I have petsc, > > babel, hypre and a couple of my others using OpenMPI on its platforms > > and LAM where there's no OpenMPI. It's a big headache! > > As one of the OpenMPI maintainers, I can just agree to that. Though the > situation might seem bad, efforts are made with upstream to support the > yet unsupported platforms. I hope we can fix that for Squeeze and am > quite confident that this is possible. We're on it, but it will take > some time. Indeed. I'm afraid I dropped the ball on bugs 471886 (extend libatomic-ops-dev) and 376833 (make OpenMPI work everywhere). I'll see if I can get some time for that, though 494046 (OpenMPI doesn't work in chroot) is my own higher priority at this point. Do you know of other ways people are working on this? > When building against OpenMPI, there are a few choices: > > 1. Do not build packages using OpenMPI on the unsupported arches. > 2. Build against OpenMPI on the supported ones, fall back to LAM on the > unsupported ones. > 3. Just build MPICH packages. > > I do not think 3. is really an option but last time I checked there > where packages doing so. This may have changed. Also, I do not recommend > building against LAM at all, since it is dead upstream. One way to > improve the current situation IMHO is to let LAM die slowly. We should > have the lib in the archive for those who need it, but we should not > build our packages against it. (This is my personal opinion, not the > opinion of the Debian OpenMPI maintainers.) As soon as Lenny is > released, I will try to check with all Debian MPI maintainers what we > can do to improve the situation and how we can implement it; but at the > moment the current situation is all we can offer. (Given in what bad > shape OpenMPI was a year ago, it's at least something to start from.) This is an interesting proposal. If LAM upstream is dead, I too would support removing its dependencies -- but leaving LAM itself for users, as you suggest. The list of packages which currently build -lam versions everywhere is: hdf5, scalapack, gromacs, netpipe, pgapack, blacs-mpi. I've submitted patches to add -openmpi versions to scalapack and blacs-mpi, which have gone ignored (my hdf5 patch was accepted). As for -lam where there's no openmpi, I only know of petsc and babel. Then again, MPICH1 is also dead upstream, and MPICH2 is not in Debian. Should we remove all of those dependencies as well? -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