Updated ABI generation code and new libraries #13280
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| .. _label-building-with-mpi-abi: | ||
|
|
||
| Building MPI applications using the MPI ABI | ||
| =========================================== | ||
|
|
||
| What is the MPI ABI | ||
| ------------------- | ||
|
|
||
| Starting with MPI 5.0, the MPI standard specifies an ABI for the c and | ||
| Fortran MPI interfaces. In this release, Open MPI supports the c | ||
| part of the MPI ABI. | ||
|
|
||
| By using the MPI ABI, an MPI application can be built against one | ||
| implementation of MPI that supports the MPI ABI, and later run using | ||
| the MPI ABI compliant MPI library generated using a different MPI | ||
| implementation. This assumes that the application is dynamically linked. | ||
|
|
||
| The MPI 5.0 standard specifies the file name of the MPI ABI compliant | ||
| library - libmpi_abi. The major version of the library is 1 and minor | ||
| version is 0. | ||
|
Comment on lines
+18
to
+20
Contributor
There was a problem hiding this comment. This is confusing. How is Open MPI going to define the SONAME? I'm assume that is going to be
Contributor
There was a problem hiding this comment. What's the soname used by mpich? If they use a different soname that defeats the whole point of having a consistent ABI
Contributor
There was a problem hiding this comment. Right now it is Again, by the Linux/libtool conventions, the SONAME should be I elaborated in the matter long ago, but I'm not sure people really understood my point.
Member
Author
There was a problem hiding this comment. yes I was going to check that (the MPICH libmpich_abi soname) as I had the same concern. Right now we are using a c/r/a that ends up generating a libmpi_abi with an soname of libmpi_abi.so.0. I wrote a blurb in the VERSION file (where we set these c,r,a for each of our Open MPI so's): I guess it should say I was thinking that if we (MPI Forum) add interfaces to the ABI we (Open MPI project) would crank up the current and age such that the C-A remains 0. And as @dalcinl notes we (MPI forum) would hopefully not do something that would case us to have to increment C and reset A to zero! I'll check out mpi-forum/mpi-abi-stubs#28 - it looks relevant. In any case I'll tweak the comment in the VERSION file.
Contributor
There was a problem hiding this comment.
Sounds good.
My initial proposal there is outdated, I originally proposed to start with |
||
|
|
||
| How to build an application using the MPI ABI | ||
| --------------------------------------------- | ||
|
|
||
| To build an application against the MPI ABI compliant Open MPI library, | ||
| the ``mpicc_abi`` compiler wrapper must be used for compiling and | ||
| linking the application or shared library. | ||
|
|
||
| This release does not support the Fortran ABI so there is no ``mpifort_abi`` | ||
| compiler wrapper. This mixed c/Fortran MPI apps cannot make use of the | ||
| MPI ABI library with this release. | ||
|
Comment on lines
+29
to
+31
Contributor
There was a problem hiding this comment. Maybe rephrase this part as per my previous comment about no Fortran ABI? |
||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not accurate. The Fortran interfaces are not part of the ABI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean the MPI_Abi_fortran* are not part of the ABI or that MPI fortran entry points in general are not part of the ABI? Section 20.4.2
The MPI ABI Fortran Modules and Shared Librarystates that there is a Fortran ABI.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one.
Maybe a leftover from @jeffhammond ?
@hppritcha What I'm trying to point out is that currently (and probably forever) it is not possible to define an interoperable ABI for Fortran. User cannot expect to compiler their Fortran code with MPICH's Fortran modules and libraries, and at runtime switch and run against Open MPI's implementation of Fortran stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
somehow i figured the fortran in the mpi_f08 module would be generic enough that it would be interoperable. I guess i need to tweak my slides for the OMPI BOF.
Okay in this light I'll scrub the fortran wording in the README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really worried that the lack of a Fortran ABI will defeat the core interoperability purpose of the ABI to the point that we the new great stuff will not adopted widely.
There is only one possible solution for Fortran: Someone (Jeff) or the community (MPICH+OpenMPI) develop Fortran bindings that use the MPI C API exclusively, and then MPI implementaitons can vendor in their releases mostly unmodified. However, such Fortran bindings would be much easier to implement if MPI fixed a few shortcomings here and there to better support callbacks/trampolines. Such enhancements would benefit other language bindings, not only Fortran.