Has anyone been able to build and link a program that uses the mpi_f08 module from MPICH 4.0 using the NAG 7.1 compiler?
I’m running into an unresolved symbol error for CFI_is_contiguous when I link. The compiler has a ISO_Fortran_binding.h file that defines CFI_is_contiguous to be __NAGf90_CFI_is_contiguous, and that latter symbol does exist in the NAG library. My best guess at this point is that the MPICH build is picking up the header file for ISO_Fortran_binding for gfortran – after all with NAG the C compiler is gcc.
I will ask on the MPICH mail list, but can’t until I am “approved”, and I’m impatient
If you are linking to a prebuilt library, it will have to be one that was built for the specific Fortran compiler you are using. Unfortunately, the C interoperability stuff from F2018 is specific to an individual Fortran compiler. If the MPI library assumes gfortran, you can’t use it with other Fortran compilers.
This is something we (Fortran committee) took a swing at, but it has proven intractable so far. It’s really too bad that this issue wasn’t considered when the feature was first being developed.
Right, I’ve built MPICH myself using gcc for the C compiler and NAG for the fortran compiler. I’ve done this for years and had no issues, but this is the first time I’ve tried to use mpi_f08 rather than the older mpi module.
I’m thinking it must be an inadequacy in the MPICH build system, which when it’s compiling the C code for the Fortran API needs to find for the correct ISO_Fortran_binding header file.
It would require a standardized layout for the “C descriptor” and standardized interfaces to the CFI_ routines. The descriptor layout is only partially specified - some fields can be reordered and there can be implementation-dependent additional fields. That part could be finessed. Harder is the specification that the CFI_ procedure names can be macros that expand to compiler-specific names (and argument order). The format of a .mod file is not an issue as the problems are all on the C side.
Well that’s interesting! It would never have occurred to me.
I tried setting CC=nagfor when building MPICH, and it does get quite a ways into the build but ultimately fails at some point due to not finding some header file mpl.h (not mpi!), so it’s not a drop-in substitute for gcc.
However, using the -# flag you mentioned did suggest I just set CFLAGS for the MPICH build to add the NAG directory that contains the ISO_Fortran_binding.h header file in the include search path. That resolves the linking error in the OP. One test runs correctly, so something is right. But another test gives an ICE on a call to an MPI subroutine. I’ll need to dig into that and take it up with support.
If the MPI library assumes gfortran, you can’t use it with other Fortran compilers.
As an aside: I did install Intel OneAPI on my Ubuntu laptop with gfortran/OpenCoarrays/MPICH already pre-installed. If I source the Intel OneAPI compiler and use OpenCoarrays/gfortran in the same terminal window, OpenCoarrays/gfortran does seem to use the OneAPI MPI version: MPI error messages are comming from the OneAPI MPI then. A recent example program to raise such error messages can be found here:
(With the OP’s example program, the call to RANDOM_SEED must be without arguments for successfull compilation with the gfortran version I am using, and it may take few minutes until the error occurs).
When I wrote about using the MPI library with different Fortran compilers, I was referring only to Fortran code that uses the MPI_F08 module and thus the MPI library tries to use the C interoperability features (which are really from F2018, but there was TS29113 that extended F08 for this, so that’s where MPI_F08 came from.)