Thank you! A patch would be great. I seem to recall that the patch in that ticket did not solve the issue for me about a year ago (was part of another discussion on OMPI Users). I did not try this time around (time reasons, sorry, the configure step just takes very long).
At this point, I found that the recommendation from the README: shell$ lt_cv_ld_force_load=no ./configure … does allow me to build a OpenMPI mpif90 that compiles a simple test program, without applying a patch - i.e., the configure file is unmodified. That's as far as I got for now. Somehow setting the environment variable "lt_cv_ld_force_load" correctly might already do the trick, as far as the original error is concerned. Best wishes Volker ________________________________ From: users <users-boun...@lists.open-mpi.org> on behalf of Gilles Gouaillardet via users <users@lists.open-mpi.org> Sent: Friday, September 16, 2022 1:41 AM To: Open MPI Users <users@lists.open-mpi.org> Cc: Gilles Gouaillardet <gilles.gouaillar...@gmail.com> Subject: Re: [OMPI users] ifort and openmpi Volker, https://ntq1982.github.io/files/20200621.html<https://urldefense.com/v3/__https://ntq1982.github.io/files/20200621.html__;!!OToaGQ!ol_3aOCUHub-qwJg-g0shVNC-LFREtjdhodGzkgca8n2FupNOU7od6bqTquhQ37bxht585bbhx2mAzp_3u22Vd8z$> (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<https://urldefense.com/v3/__http://autogen.pl__;!!OToaGQ!ol_3aOCUHub-qwJg-g0shVNC-LFREtjdhodGzkgca8n2FupNOU7od6bqTquhQ37bxht585bbhx2mAzp_3gPybF3Q$> (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<mailto:users@lists.open-mpi.org>> wrote: Hi all, This issue here: https://github.com/open-mpi/ompi/issues/7615<https://urldefense.com/v3/__https://github.com/open-mpi/ompi/issues/7615__;!!OToaGQ!ol_3aOCUHub-qwJg-g0shVNC-LFREtjdhodGzkgca8n2FupNOU7od6bqTquhQ37bxht585bbhx2mAzp_3oBmY0ia$> 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<https://urldefense.com/v3/__https://github.com/open-mpi/ompi/issues/7615__;!!OToaGQ!ol_3aOCUHub-qwJg-g0shVNC-LFREtjdhodGzkgca8n2FupNOU7od6bqTquhQ37bxht585bbhx2mAzp_3oBmY0ia$>) 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?