In trying to upgrade our build of mpich to 4.2.2 from 4.1.2, I notice that the libraries are not completely binary compatible - at least, not in the way that our system presumes will be the case. We currently support users bringing their own MPI, providing it is ABI-compatible with our "primary" MPI, which is whatever current release of mpich we're using. In the past, this has meant that in practice, because nothing we do needs the very latest functionality provided by mpich, even very old mpich-derivative MPIs would work.

With mpich-4.2.2, I see from the CHANGES file that many of the functions that were implemented as macros (e.g. MPI_Comm_f2c) are now "real" functions – to support the requirements of the MPI-4.1 standard. I notice further that the implementation of those functions is basically the same as the old macro.

For now, I'm planning to work around this by effectively using the old macro definitions for cases where a user-supplied MPI library doesn't provide the necessary entry points. Does that seem reasonable?

In fact, I note this PR https://github.com/pmodels/mpich/pull/6711 in which Ken Raffenetti says:

“Just thinking from the ABI perspective, I don't think there is any backwards compatibility concern. Apps compiled when these were macros will continue to work with newer MPICH libraries.”

So, I infer from that comment that the approach I’m contemplating should be fine.

I imagine the other ABI-compatible libraries listed here https://www.mpich.org/abi/ will eventually adopt this change too – I don’t suppose there is any known timeline when this might happen?

Cheers,

Edric.