-
Notifications
You must be signed in to change notification settings - Fork 885
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mac OS Mojave undefined _ompi_buffer_detach_f08 #7615
Comments
I was seeing odd things too, but my in your build dir, could you please
you should see something like
and then
you should see something like
note the and then
hopefully, you should see
|
I get:
I get:
I get the base/libusempif08_ccode.la near the end but I'm more concerned with the -force_load warnings. I checked the output of the original make and the warnings appear there as well. When I check the configure output it reports that libtool accepts -force_load. I will look into this further but if anyone has a quick fix or explanation, it would be appreciated.
It's currently rebuilding from scratch but I checked libmpi_usempif08.dylib after the steps above and _ompi_buffer_detach_f08 was still undefined. |
Thanks, it looks like Can you try to manually run the
|
Manually replacing -force_load works and produces a usable Open MPI. Thanks! However, adding "-Wl," before "-force_load" also works and is probably a more workable solution. Thanks for idea of taking flag recognition out of ifort's hands. I'm busy with other things right now but I will investigate this further if/when I get a chance. I'm guessing the developers there probably know how to correct it already. Thanks again! |
Thanks, it looks like we will have to patch the generated |
I found this https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/763137 TL;DR
|
an other thing worth trying is to use Apple's autotools in the source directory, you can run
and then try again to build Open MPI |
an other workaround is at https://git.ustc.edu.cn/qqq/linuxbrew-core/commit/61b85a5e3b425439098f25c7f7ef33c76253943c TL;DR
|
Thanks for the hints here! I manually edited libtool to add the -Wl, for ifort, and that worked. (I'm on High Sierra with ifort 13 (I know -- old!) |
@ggouaillardet Would this also be related to having problems with MPI_IN_PLACE not working? I was able to compile 4.0.3 (clang + ifort), and mpif90 creates executables. But ALLREDUCE using MPI_IN_PLACE return zero because apparently MPI_IN_PLACE has a value of zero. |
@MicroTed please open a new issue and describe your environment (fwiw, |
@MicroTed BTW, this (i.e,. the ompi_buffer_detach_f08 issue) was fixed on the v4.0.x branch for the upcoming v4.0.4 release. Would you mind giving the latest v4.0.x nightly snapshot tarball a whirl to make sure we got it right? |
@jsquyres Sure, I can try it. I'll also post a new issue for the mpi_in_place, though I wonder if it's an ifort problem. Might be overdue for a new license :) |
In that nightly build (openmpi-v4.0.x-202004210241-ed358e5), I see that libtool has
So it appears not to recognize that ifort needs wl="-Wl," And I get the warnings: |
What was fixed was the missing We didn't patch Libtool to fix warnings. |
Sorry, I guess I forgot to add that the library error still occurs: tmimac:ted.mansell% which mpif90 |
I might have accidentally mixed up which bug this issue referred, to -- I thought it was referring to the missing Did you try @ggouaillardet's suggestion of:
and/or raising the issue with Intel? The issue here is that Libtool is a third-party tool; having us patch it is fairly painful, fragile, and error-prone. If there is an incompatibility here between |
Ah, I'm not so familiar with libtool, or configure for that matter -- just enough to hopefully get stuff compiled. It's interesting that configure figures out that ifort needs -Wl, (according to config.log) but doesn't output that to config.status. I don't have a current ifort license, but I probably should update this year if I can. I just figured out what I did wrong with "lt_cv_ld_force_load=no" so I will try that again. Edit: That does work! |
For comparison, I tried out mpich (3.3.2) after not having used it for years. Its configure does set up -Wl, in the config.status, compared to the config.status from openmpi: < lt_prog_compiler_wl_FC='-Wl,'
< lt_prog_compiler_wl_F77='-Wl,'
---
> lt_prog_compiler_wl_FC='' (It has an additional section for F77) And then the libtool has that, too. If I knew anything about the configure process, I'd try to help with that. |
didn't get fixed in 4.0.4 |
I made some tweaks to 'configure' script and now it works. https://ntq1982.github.io/files/20200621.html macOS Sierra 10.12.6 |
We talked about this issue in our weekly Open MPI engineering roundup and came to the conclusion that you should probably raise this with Intel support. The issue is generic to GNU Libtool -- it is not specific to Open MPI. |
@ntq1982 Did you raise this with Intel support? We're curious as to what they said. |
@ntq1982 We're closing this because we think that this is an Intel compiler issue. Please feel free to let us know how it went with Intel support. |
Per open-mpi#7615 (comment). Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Per open-mpi#7615 (comment). Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Per open-mpi#7615 (comment). Back-ported to the README (not README.md) on the v4.1.x branch. Signed-off-by: Jeff Squyres <jsquyres@cisco.com> (cherry picked from commit c1df265)
Per open-mpi#7615 (comment). Signed-off-by: Jeff Squyres <jsquyres@cisco.com> (cherry picked from commit c1df265)
Per open-mpi#7615 (comment). Back-ported to the README (not README.md) on the v4.0.x branch. Signed-off-by: Jeff Squyres <jsquyres@cisco.com> (cherry picked from commit c1df265)
@jsquyres A query. I saw in the notes for v4.1.5:
and was wondering, is it this issue? Or something different? I ask only because I think the change references: https://ntq1982.github.io/files/20200621.html which seems to have the same |
I have built Open MPI v4.0.3 from the bzipped tar ball with the Intel 19.0.5.281 compilers (icc, icpc, ifort). I have enabled the C++ bindings with the --enable-mpi-cxx configure option because we need those bindings for some coupling software (ESMF) we use. My configure line is:
CC=icc CXX=icpc FC=ifort ../../ompi/configure --prefix=//openmpi-4.0.3-intel --disable-silent-rules --enable-mpi-cxx
As you can see I am doing a vpath build. The system is an iMac Pro running the latest (10.14.6) Mojave. We can't upgrade to Catalina because we use the TotalView debugger extensively and it's not supported on Catalina yet.
The issue is at the linking stage of compiling with Open MPI mpif90 I get the following error:
When I look at libmpi_usempif08.dylib, sure enough, _ompi_buffer_detach_f08 is undefined:
None of the other libraries even reference _ompi_buffer_detach_f08. However, we have several older versions of Open MPI that work fine with the software I'm trying to build. For example, when I do the same thing on the identically configured and built 3.1.3 version of Open MPI, which builds and runs the software successfully, _ompi_buffer_detach_f08 is defined:
Same goes for the 2.1.6 version that was also built with the same configure options. A quick comparison between 3.1.3 and 4.0.3 shows only the location of buffer_detach.c (where ompi_buffer_detach_f08 is defined) has changed; the actual code seems to be identical. Is it possible that something needs to be adjusted in the make files to account for the new location of buffer_detach.c?
The text was updated successfully, but these errors were encountered: