I generally agree, just a quick nit-pick/clarification: On Tue, 2009-11-10 at 20:56 +0100, Manuel Prinz wrote: > * Alternatives need to be fixed. Besides what the bugs that > Nicholas referenced say, there are two other issues with those: > First, the priorities do not match the reality (Open MPI being > the default / recommended implementation to use), and second, > that mpi.so is also in the alternatives, which is wrong in every > respect and has bother me for a very long time now. The > implementations are not ABI-compatible in any way, and we really > need to get rid of that. The .so alternatives symlinks only require that the libraries be API-compatible, which they are (or if not, it's a bug, since they're supposed to follow the MPI standard). That's why these links, and plain .so links in general, are in the -dev packages, not the shlib packages. It should be possible to compile any MPI program's source code against any implementation by linking -lmpi -lmpi++ etc. Then the resulting binary, shlib etc. includes the soname specific to the library it linked with, e.g. libopen-rte.so.0 . So if it's in a Debian package, the resulting binary depends on the ABI-correct library package, e.g. libopenmpi1 . If this still doesn't make sense, the libtool online documentation is pretty clear. -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