[mpich-discuss] mpich-4.2.2 and ABI compatibility

[Zhou, Hui]

I agree to all your guesses 🙂

--
Hui
________________________________
From: Edric Ellis via discuss <discuss at mpich.org>
Sent: Wednesday, July 31, 2024 4:39 AM
To: discuss at mpich.org <discuss at mpich.org>
Cc: Edric Ellis <eellis at mathworks.com>
Subject: [mpich-discuss] mpich-4.2.2 and ABI compatibility

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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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://urldefense.us/v3/__https://github.com/pmodels/mpich/pull/6711__;!!G_uCfscf7eWS!dh3e5A75ZFz9h6lS2S47DDIaelASIxljDXAYdYO9wuJe3Cenh90g5lAHAhKgtojGLwVJaTZRchsd$ <https://urldefense.us/v3/__https://github.com/pmodels/mpich/pull/6711__;!!G_uCfscf7eWS!Z3GeBsC316MCjTu8YURSwe1I9OQ3wkymnX6m94M4N_viWPFXmLUnJV1U9cRUS2NzyVUG2yyB642BD1o$> 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://urldefense.us/v3/__https://www.mpich.org/abi/__;!!G_uCfscf7eWS!dh3e5A75ZFz9h6lS2S47DDIaelASIxljDXAYdYO9wuJe3Cenh90g5lAHAhKgtojGLwVJafsoCYOI$ <https://urldefense.us/v3/__https://www.mpich.org/abi/__;!!G_uCfscf7eWS!Z3GeBsC316MCjTu8YURSwe1I9OQ3wkymnX6m94M4N_viWPFXmLUnJV1U9cRUS2NzyVUG2yyBNJ9d9P8$> will eventually adopt this change too – I don’t suppose there is any known timeline when this might happen?



Cheers,



Edric.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20240801/ec020289/attachment.html>