[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: building package with different libs

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

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

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

Best regards
Manuel, with his OpenMPI maintainer hat on

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply to: