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

Bug#573187: transition: mpi-defaults

Hi Lucas,
I'm a little lost trying to find the platform where the build is failing. Can you point me to the exact output? 

Thanks,

 -- Pavan

Lucas Nussbaum wrote:

Hi Pavan,

Could you take a look at http://bugs.debian.org/573187 and at the
message below?

We would like to switch to using mpich2 on the arches where openmpi is
not supported, but some packages fail to build from source when using
mpich2. It seems that for some of them, it is caused by build systems
expecting to find mpi.h in /usr/lib/mpich2/include/ (as it is the case
for other MPI implementations), while it is shipped in
/usr/include/mpich2/.

This seems like something that would be better fixed upstream, even if I
agree that the file location in openmpi is a bit strange. What do you
think?

- Lucas

On 06/04/10 at 19:41 +0200, Manuel Prinz wrote:

Am Montag, den 05.04.2010, 17:22 +0200 schrieb Marc 'HE' Brockschmidt:

So, did you spend this time on doing fixes already? :-)

Yes, I indeed did. Not as much as I'd liked too, but nevertheless.


It would be great to see at least a few patches for the breaking
packages before the new defaults package is uploaded.

I'll just repeat the list of failing packages here and comment on them
group-wise.

Patch available:
      * rmpi: patch attached
      * blacs-mpi: patch attached
      * mumps: Can be rebuild against fixed blacs-mpi

CMake:
      * igstk
      * kwwidgets
CMake does some magic here which I do not understand yet. These seem to
fail because they look for a library openmpi provides but mpich2
doesn't. (Well, at least not under that name.) We might fix that via a
symlink in mpich2, or I've to dive deeper into CMake.

Wrong location of header file (mpi.h) at configure:
      * apbs
      * petsc: almost done, minor issue remaining
There may be more packages in this group, the already patched ones are
also of this type. Most upstream build systems seem to expect
a /foo/{include,lib} hierarchy, and you can only pass the location
of /foo to the build system. Some are flexible enough to work around
that (see patches) but I do not see how to do that for apbs easily.
(It's possible for petsc but my patch has some other issue I have to
track down.) This could easily be fixed it mpich2 would provide this
hierarchy, as we already discussed. It would make the patches much
simpler, some packages of these 11 wouldn't even need patching then. I
think we should reconsider the option of doing the change in mpich2.
(Note: MPICH and LAM did provide this hierarchy, too.)

Remaining packages:
      * life: Might be fixed with petsc, not sure yet.
      * gdcm: Not looked at yet
      * pgapack: Not looked at yet
      * scalapack: Seems to be of type "wrong location", may need no fix

This is the status as of now. I'm working on the remaining patches, but
the proposed change to mpich2 would save us some time here, as it avoids
patching about half of the packages at all. Please let me know what you
think about that.

Best regards,
Manuel







--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
Reply to: