Manuel Prinz wrote:
The problem is that a lot of build systems of MPI-using software want the headers in $prefix/include and the libs in $prefix/lib, and on can often only use $prefix to point to the location of MPI-relevant files. The Debian package of MPICH2 uses $prefix/lib and $prefix/include/mpich2 which a lot of build systems do not like or handle correctly. This is why the openmpi package uses --prefix=/usr/lib/openmpi to build and symlinks the libraries to /usr/lib. This way, everything works as expected. Not pretty, but effective. The questions is whether we apply that change to the mpich2 package, as it was for all MPI packages in Debian so far, or fix every broken build system out there. [0]
If we choose to do the first approach, what exactly needs to change in the mpich2 source? It looks like this is more of a packaging issue for Debian?
Still waiting for the day when MPI standardizes on ABI, not API… But that may be wishful thinking.
We were having a discussion about a common ABI in the context of MPI-3. But that working group fizzled out. I'll check on what exactly happened with it in the next meeting (in May). Even if the MPI standard doesn't specify ABI compatibility, I'll talk to the Open MPI folks to see if MPICH2 and Open MPI do whatever the ABI working group was proposing outside of the standard, which might be sufficient for you guys.
-- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bbe652a.9090...@mcs.anl.gov
