Bug#573187: transition: mpi-defaults
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
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: