Just for clarification: we had a little internal discussion here about
this topic. I fear LANL's interest in this may be somewhat
Basically, a few users here have expressed that it would be
"convenient" if they could switch MPI implementations without
recompiling - that is our complete level of interest in this topic.
There are no plans to request this in future procurements, no
willingness or interest in devoting LANL resources to accomplishing
it. We have much higher priorities than this one.
If others in the community have some interest in pursuing it, they are
welcome to do so. We are not discouraging anyone from doing so - just
making our position on this clear so people can understand why we
aren't stepping forward on it.
On Sep 9, 2008, at 6:23 AM, Jeff Squyres wrote:
> On Sep 9, 2008, at 2:45 AM, Ralf Wildenhues wrote:
>>> At the MPI Forum meeting in Dublin, the MPI ABI meeting was... er...
>>> shall we say, "spirited." :-) Both the benefits and drawbacks of
>>> MPI ABI are widely contended (it's a surprisingly complex topic).
>> it sounds quite daunting.
> It is. :-)
>>> - If it is ever completed, MPI ABI compliance will be a separate
>>> from the MPI 2.x and 3.x standards. ABI compliance will be a
>>> for an MPI implementation, but will be unrelated to an
>>> 2.1, 2.2, 3.0, ...etc. compliance.
>> How can that be possible? An MPI ABI will have to be versioned in
>> the same way that the API is versioned. You can have an ABI version
>> for each API version though, I guess.
> That is correct. My first statement wasn't entirely correct --
> "unrelated" is probably not quite the correct word. Each ABI
> version will be tied to a specific API version. What I was trying
> to say is that an implementation can be claim to be API compliant,
> even if it's not ABI compliant.
>> And of course the MPI C++ ABI will require specifying a C++ ABI
>> (which, for Windows, means specifying the compiler and possibly its
>> major release number used), but this is venturing off into details.
> Not just Windows, right?
> Ditto for Fortran.
> Jeff Squyres
> Cisco Systems
> devel mailing list