RFE: Don't link to MPI Fortran interface libraries

[jabl]

It would be nice if the OpenCoarrays MPI library would link only to the C MPI library. At least with openmpi, it currently links also to the Fortran interface libraries. E.g. on Ubuntu 18.04 using the system openmpi 2.1.1-8:

 > ldd lib/libcaf_mpi.so
        linux-vdso.so.1 (0x00007ffec4589000)
        libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f2f98eaa000)
        libmpi_usempif08.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_usempif08.so.20 (0x00007f2f98c7a000)
        libmpi_usempi_ignore_tkr.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_usempi_ignore_tkr.so.20 (0x00007f2f98a74000)
        libmpi_mpifh.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_mpifh.so.20 (0x00007f2f9881d000)
        libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f2f9843e000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2f980a0000)
        libgcc_s.so.1 => /home/janne/src/gfortran/trunk/install/lib64/libgcc_s.so.1 (0x00007f2f97e88000)
        libquadmath.so.0 => /home/janne/src/gfortran/trunk/install/lib64/libquadmath.so.0 (0x00007f2f97c48000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2f97857000)
        libopen-rte.so.20 => /usr/lib/x86_64-linux-gnu/libopen-rte.so.20 (0x00007f2f975cf000)
        libopen-pal.so.20 => /usr/lib/x86_64-linux-gnu/libopen-pal.so.20 (0x00007f2f9731d000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2f97115000)
        libhwloc.so.5 => /usr/lib/x86_64-linux-gnu/libhwloc.so.5 (0x00007f2f96ed8000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2f96cb9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2f993ba000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2f96ab5000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2f968b2000)
        libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f2f966a7000)
        libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f2f9649d000)

Here, the libraries libmpi_usempif08, libmpi_usempi_ignore_tkr and libmpi_mpifh are Fortran interfaces to the "actual" C MPI library libmpi.

If OpenCoarrays would depend and link only to the C MPI library, it would make life easier, as one would likely be able to use the MPI library provided via the system packages rather than having to build one oneself for each Fortran compiler and compiler version that one wishes to use.

[rouson]

Hi @jabl,

That would work in the short-term, but there's ongoing discussion about implementing some parts of the libcaf_mpi in Fortran. If we go that route, we would definitely want to take advantage of the mpif08 module defined in the MPI standard so at least the link to libmpi_usempif08 would come back. In fact, I'd very much like to see some parts of libcaf_mpi implemented in Fortran for several reasons so I'd say it's more than just a discussion. It's a desire and the only question is staffing the effort and evaluating the success of it as we progress. I'll leave it to @zbeekman to decide whether to disable linking to the named libraries for now and then pull them back in when necessary.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[cprich01]

agree the problem is getting coarrays through all the wrappers with all the different tweeks.

[zbeekman]

It should be feasible to implement this enhancement. I don't know if anyone has time or funding to do so at the moment, however. I agree that it would improve portability and robustness of distributed versions (like via Homebrew)

[cprich01]

I think most people with my experience using opencoarrays will experience the issues that I am experiencing.  That is not understanding fully its use.  I was trying to install it but I am not fully familiar with an underlying technology, openmp, which does the same thing internal to the system.  So I digress until I can do troubleshooting.  Thanks for follow up.Sent from my iPhoneOn Aug 6, 2024, at 11:06, zbeekman @.***> wrote: It should be feasible to implement this enhancement. I don't know if anyone has time or funding to do so at the moment, however. I agree that it would improve portability and robustness of distributed versions (like via Homebrew)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>