Volker, https://ntq1982.github.io/files/20200621.html (mentioned in the ticket) suggests that patching the generated configure file can do the trick.
We already patch the generated configure file in autogen.pl (if the patch_autotools_output subroutine), so I guess that could be enhanced to support Intel Fortran on OSX. I am confident a Pull Request that does fix this issue will be considered for inclusion in future Open MPI releases. Cheers, Gilles On Fri, Sep 16, 2022 at 11:20 AM Volker Blum via users < users@lists.open-mpi.org> wrote: > Hi all, > > This issue here: > > https://github.com/open-mpi/ompi/issues/7615 > > is, unfortunately, still current. > > I understand that within OpenMPI there is a sense that this is Intel's > problem but I’m not sure it is. Is it possible to address this in the > configure script in the actual OpenMPI distribution in some form? > > There are more issues with OpenMPI + Intel + scalapack, but this is the > first one that strikes. Eventually, the problem just renders a Macbook > unusable as a computing tool since the only way it seems to run is with > libraries from Homebrew (this works), but that appears to introduce > unoptimized BLAS libraries - very slow. It’s the only working MPI setup > that I could construct, though. > > I know that one can take the view that Intel Fortran on Mac is just broken > for the default configure process, but it seems like a strange standoff to > me. It would be much better to see this worked out in some way. > > Does anyone have a solution for this issue that could be merged into the > actual configure script distributed with OpenMPI, rather than having to > track down a fairly arcane addition(*) and apply it by hand? > > Sorry … I know this isn’t the best way of raising the issue but then, it > is also tiring to spend hours on an already large build process and find > that the issue is still there. If there was some way to figure this out so > as to at least not affect OpenMPI, I suspect that would help a lot of > users. Would anyone be willing to revisit the 2020 decision? > > Thank you! > > Best wishes > Volker > > (*) I know about the patch in the README: > > - Users have reported (see > https://github.com/open-mpi/ompi/issues/7615) that the Intel Fortran > compiler will fail to link Fortran-based MPI applications on macOS > with linker errors similar to this: > > Undefined symbols for architecture x86_64: > "_ompi_buffer_detach_f08", referenced from: > import-atom in libmpi_usempif08.dylib > ld: symbol(s) not found for architecture x86_64 > > It appears that setting the environment variable > lt_cx_ld_force_load=no before invoking Open MPI's configure script > works around the issue. For example: > > shell$ lt_cv_ld_force_load=no ./configure … > > This is nice but it does not help stop the issue from striking unless one > reads a very long file in detail first. Isn’t this perhaps something that > the configure script itself should be able to catch if it detects ifort? > > >
