Mark Hahn wrote:
>>There are only 2 ways to achieve ABI compatibility:
>>1) you impose/agree on a single one.
> ignoring the politics for a moment, what are the technical sticking points?
> for instance, I have the impression that the linux x86_64 ABI is reasonably
> well-defined, and it seems to permit use of at least some libraries
> across different compilers in my experience. so what are the problem areas?
> just that the MPI Forum has chosen/failed to define constants and proper
> opaque types?
Basically, you need a reference mpi.h/mpif.h, including constants values
and type definitions. However, it's not enough, you have to define some
implementation details. For example, there is no pointers in Fortran, so
MPI implementations should agree on the conversion method between
integer and (pointer to) types. For the types themselves, you would need
to replace the implementation specific fields with a pointer/reference
to an opaque internal type.
I believe it can be done with a commitment from the MPI implementors,
but it's more than just pushing a new mpi.h and recompiling.
Furthermore, there is no standard binary interface in Fortran, so you
cannot safely use a library compiled with one compiler and an
application compiled with another. So, ISVs would have to ship several
binaries for linking with differents MPI libraries, or pick one
supported Fortran compiler. Testing/validating would still have to be
done per compiler, so it's likely that they would pick one.
In retrospect, the choice of the MPI forum to not put constraints on the
implementation was a good one. Now that MPI is pervasive, it's
legitimate to care about an ABI, but it would certainly have been a
weight for the adoption of the standard back in the days.