History

Full support for the PMPI_ interface in AMPI would require some invasive changes to AMPI:1. Define each MPI_ routine in its own file. This would mean breaking up ampi.C, ampiOneSided.C, and ampiMisc.C into >300 files. This is necessitated by the non-portability of weak symbols and the fact that users/libs can choose to intercept only some of their MPI_ routines with PMPI_ wrappers and to treat the others as normal MPI_ routines.2. Instead of using AMPI_ internally and using the preprocessor to rename MPI_, we would need to define everything in AMPI to MPI_ in order to use weak symbols. This would break AMPI's ability to build on the MPI net-layer.

We could potentially support the PMPI_ interface ONLY on platforms supporting weak symbols AND on non-MPI layer builds (multicore, netlrts, verbs, gni, pamilrts), but this needs more thought... In the end, virtualization will break probably all existing profiling libraries too. It might be worth maintaining this in a branch of AMPI, but not in production unless we want to do it properly with full portability + support.

It makes sense to me. If you already have a small test working then I'd say go ahead. Even if it didn't work on the MPI layer it would still be valuable, and I think all compilers that we care about support weak symbols.

Linux support:Works on {netlrts,mpi}-linux-x86_64. Tested on CentOS6, CentOS7, Ubuntu17.10 with their default compilers.

Darwin support:No support. I think weak symbol aliases are not supported on Darwin. MPI applications work as before, but cannot use PMPI.

Windows support:Untested. Doesn't build at the moment, even without the patch above. As the Win* targets use PE32 as file format for executables (not ELF), it is unlikely that PMPI is supported on Windows.

Note that the actual implementation is slightly different from the one pointed out above.