[mpich-discuss] Implicitly remove "mpif.h" support?

[Zhou, Hui]

Just to follow up. It turns out that we just need add -Wl,-flat_namespace​ in linking libmpifort.so​. So all good for now.

--
Hui
________________________________
From: Zhou, Hui via discuss <discuss at mpich.org>
Sent: Thursday, February 22, 2024 1:42 PM
To: discuss at mpich.org <discuss at mpich.org>
Cc: Zhou, Hui <zhouh at anl.gov>
Subject: [mpich-discuss] Implicitly remove "mpif.h" support?

First, are there folks who still maintain or need to work with legacy Fortran code that relies on include 'mpif.h​ interface?

Our CI testing machine for Macos recently upgraded and left us (MPICH development) with some regression failures. The failures are from not recognizing special constants such as MPI_BOTTOM and MPI_IN_PLACE. These constants are implemented using COMMON BLOCK​. For those who are not familiar, COMMON BLOCK allows different FORTRAN objects to declare global variables and to be merged at link time. The upgraded dyld​ on Mac refuse to do that between user code and libmpifort.dylib​, resulting in constants such as MPI_IN_PLACE​ not being recognized.

The better way of implementing global variables in Fortran is via the module interface. But what about those legacy codes that can't be updated?

Here are the options:

1. Figure out a way to make COMMON BLOCKS on modern Mac work – we need help!

2. Leave it as is - everything will work except legacy Fortran on MacOS. We add a note in the documentation and move on.

3. Suggest users to use mpi​ instead. But if that suggestion will always work, maybe we can put "use mpi" inside "mpif.h" – assuming that all Fortran compilers are able to support the module interface today even when users don't realize that.

The option 3 is what the subject line refers to.

Feedback?

--
Hui Zhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20240224/d033374b/attachment.html>