MPI build appears successful but actually excludes MPI about fpm HOT 5 CLOSED

I believe linking of the executable cannot be successful if any calls to MPI libraries are made, and the code is not linking against any libraries that contain them.

Looking at Bad system #1, you have gfortran + OpenMPI which is a supported configuration, so please help us understand if there is a bug:

• What is the output of the build process of --verbose?
• It seems like that version of OpenMPI 4.1.2 has issues. Please share the output of mpif90 --showme and mpif90 --showme:link, that may help us understand what's going on better.

from fpm.

Sure thing. Here's mpif90 --showme:

gfortran -I/usr/lib/x86_64-linux-gnu/openmpi/lib/../../fortran/gfortran-mod-15/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib/fortran/gfortran -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -lopen-rte -lopen-pal -lhwloc -levent_core -levent_pthreads -lm -lz

And mpif90 --showme:link:

-I/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib/fortran/gfortran -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -lopen-rte -lopen-pal -lhwloc -levent_core -levent_pthreads -lm -lz

Here's the verbose build output, in a file because of length:
fpm_build_verbose.txt

from fpm.

Thank you!
From your output, it seems like the MPI libraries are correctly linked into the executable also during the final link step, so, the only reason I believe they may not end up into the executable is because no functions from them are ever called. Could this be related to calls to MPI routines i.e. MPI_Init be due to pre-processor macros ?

from fpm.

I think I figured it out. There's a file that defines dummy versions of all the MPI subroutines that are used, I think to accommodate running without MPI after building with MPI. (I inherited this codebase, so I'm not entirely sure of the intent here.) Deleting that file causes the linking to succeed on Bad system 1, and Good system continues to succeed.
It seems like there was a name collision between the dummy and MPI subroutines, where the good case prioritized the MPI and the bad case prioritized the dummy. Does that sound plausible to you?

However, Bad system 2 now shows undefined references to all the MPI subroutines at the final linking step:

[...]
pen_surface.F                          done.
pen_setup.F                            done.
emu_main.F                             done.
libemu.a                               done.
emu                                    failed.
[100%] Compiling...
build/gfortran_D85B94C7BF1DD83C/emu/libemu.a(src_emu_main.F.o): In function `emumain_':
emu_main.F:(.text+0x737): undefined reference to `mpi_finalize_'
emu_main.F:(.text+0x2391): undefined reference to `mpi_finalize_'
build/gfortran_D85B94C7BF1DD83C/emu/libemu.a(src_modules_md_util.F.o): In function `__md_util_MOD_wrapup':
md_util.F:(.text+0xc3f): undefined reference to `mpi_finalize_'
build/gfortran_D85B94C7BF1DD83C/emu/libemu.a(src_exchange_exchange_init.F.o): In function `exchange_init_':
exchange_init.F:(.text+0x4b): undefined reference to `mpi_initialized_'
[...]
exchange_tearing.F:(.text+0xc44): undefined reference to `mpi_allreduce_'
collect2: error: ld returned 1 exit status
<ERROR> Compilation failed for object " emu "
<ERROR> stopping due to failed compilation
STOP 1

from fpm.

This falls back to #974, so I will close this issue.

from fpm.