RE: [mpi-21] Call for MPI 2.2 and 3.0 agenda items for the Jan meeting

[Ashley Pittman <apittman@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, 2007-12-04 at 09:00 -0800, Erez Haba wrote:
> The feedback I am getting back from ISVâs is that the two most
> important issues for the C ABI are

I've extended this list with three other things you'll need.

> 1.      Calling convention
> 
> 2.      Size of input parameters (e.g., whatâs the size of MPI_Comm)

3. The values of some constants, e.g. MPI_COMM_WORLD

> I didnât hear any ISV ask for unified binary name, and think that this
> would be unwise to do so.

4. You need a unified binary name.  Otherwise your program would not
link.

> Having binaries clash with each other is a deployment nightmare.

I don't know much about Windows but on Unix this is traditionally
largely solved by the major version number of the library.

5. A library major number.

I recommend this webpage for anyone not familiar with library version
numbers, http://www.ibm.com/developerworks/linux/library/l-shlibs.html
What is supposed to happen is when a given library has a API change the
minor number is incremented and when there is a ABI change the major
number is incremented.  When a program is compiled it's linked against
the library with the highest major number and this number is stored in
the executable.  At run-time differences in minor number are ignored but
if a library with a matching major number is not found the program will
not link.

Taking this minimalist view as to what a ABI should cover, what Greg
refers to in his talk as the easy part, I think there would be a good
case for this being a de-facto standard rather than anything prescribed
by the forum.

Of course all this only applies to c, as far as I can see c++ itself
doesn't have a ABI that spans compiler versions and Fortran doesn't have
a ABI that allows you covers multiple compiler vendors.

Ashley,