pip install error

[Michiel Karrenbelt]

I'm having issues installing mpi4py on macOS 10.14.3, using python 3.6.6. I installed I had to install open-mpi (v4.0.1), which worked; I was to run the test as suggested in this post: https://stackoverflow.com/questions/42703861/how-to-use-mpi-on-mac-os-x

I still cannot install mpi4py (tried 3.0.1, 3.0.0 and 2.0.0, all fail). It starts with a linker command that fails (for the llmpe library, and others), and then reports on unexpected expressions and outdated symbols in the code. The output in full is attached as a text file. Please let me know if you need more information from my side, or if you have suggestions how to address this.

best, Michiel

[Lisandro Dalcin]

Well, Open MPI messed around with the definitions of MPI_LB/MPI_UB in mpi.h from release 4.0.0 to 4.0.1, nice move to do that in a patch release. I'm working on a hotfix.

[Lisandro Dalcin]

Fixed in 42f5e35. This fix will be available in upcoming mpi4py release 3.0.2, in the mean time you can:

$ pip install https://bitbucket.org/mpi4py/mpi4py/get/maint.tar.gz

[Ashwin Vishnu]

I hope this would be released soon, since ArchLinux has been on openmpi 4.0.1 for a while.

[Lisandro Dalcin]

Or you can file a bug in Open MPI and tell them that they should not mess with their own headers in a patch release. Or you can file a bug in ArchLinux, so they build Open MPI with MPI 1.x compatibility. Or you can pip install https://bitbucket.org/mpi4py/mpi4py/get/maint.tar.gz.

[Ashwin Vishnu]

You are right this is an OpenMPI bug, and it can potentially affect other appications which rely on it. Thanks, I will see what I can do.

Ashwin

[Ashwin Vishnu]

Reported https://github.com/open-mpi/ompi/issues/6601

[Ashwin Vishnu]

Arch Linux is already tracking a related issue: https://bugs.archlinux.org/task/61764

[Jeff Squyres]

I'm one of the Open MPI developers.

I apologize for the churn and the confusion that has occurred regarding the MPI-1 legacy constructs. We tried to communicate this widely before the v4.0.0 launch (indeed, we started emitting legacy compilation warnings back in the v3.0.x series), but inevitably we didn't reach everyone. It also didn't help that we didn't get it right in the v4.0.0 release (i.e., the legacy symbols were still available in mpi.h by default).

I realize that mpi4py is caught in the middle of all of this: mpi4py still has to provide these legacy constructs because applications haven't updated yet. We're really sorry about that. Indeed, we're sorry about the confusion we caused, and the trouble that moving legacy applications forward is going to cause. We realize that everyone will not want to have to edit their existing codes to remove the legacy constructs.

Specifically: we realize that this change is causing work for the application community. We're sorry about that. Please know that it really does help the implementor community move forward.

Let me explain what our goals are, why we're doing it, and ask for your help.

1. We are trying to move forward with the MPI spec and start leaving some of the legacy pieces behind -- especially those that have a nonzero cost of maintaining. For example, MPI_LB/UB actually does cost developer time and effort to maintain, and affect not only the Open MPI datatype engine, but also the features/functionality surrounding the datatype engine. These MPI-1 legacy constructs were deprecated in 1996 -- that's over 20 years ago. They were finally removed from the MPI spec in 2012. As a developer community, we have finite resources: we need to be able to focus on where MPI is going, not where it has been.
2. Our goal was to -- by default -- remove these legacy constructs from mpi.h and still leave them in the library so that Open MPI apps compiled against v3.0.x and v3.1.x would still be ABI-compatible with v4.0.x. This would give apps time to transition away from these ancient APIs. Unfortunately, we screwed up and accidentally left MPI_UB (and friends) in mpi.h in the v4.0.0 release. That has been fixed in the v4.0.1 release: by default, MPI_UB (and friends) are no longer in mpi.h. But the corresponding symbols are still in the MPI library.
3. Another fix is to use the --enable-mpi1-compatibility configure command line switch when building Open MPI v4.0.x (where x = any value -- this switch will be there for the entire 4.0.x release series). That will restore the legacy constructs in mpi.h.
4. That being said, --enable-mpi1-compatibility is a temporary band aid that will almost certainly disappear in a future release series of Open MPI. The intent with the v4.0.x series is to raise awareness so that the application community can start having the discussion about how to avoid using these legacy constructs. I.e., we imagined that this scenario would play out many times:
   1. "Hey, my code no longer compiles with Open MPI v4.0.x!"
   2. Post to the Open MPI mailing list / github / some other internet forum
   3. Receive a reply about the MPI-1 legacy constructs, and how you can use --enable-mpi1-compatibility to immediately restore your application
   4. With an --enable-mpi1-compatibility-enabled Open MPI, be reminded of these legacy constructs every time you compile (because you'll see legacy compilation warnings)
   5. Hopefully eventually look at https://www.open-mpi.org/faq/?category=mpi-removed and get advice on how to update your MPI application on how to avoid the legacy constructs
5. Please please please help us spread the word: get applications to update away from these constructs that were deleted from the MPI specification in 2012. It's a nonzero amount of work for application maintainers, but hopefully it's not a lot of work.

Updating these applications will help the entire MPI community move forward.

Many thanks for your patience, especially if you read this entire (lengthy!) post.

[Lisandro Dalcin]

@jsquyres Now I realize my wording was quite strong and impolite, I was having a rough day. It was not my intention to offend you, I really appreciate you despite I do not know you in person.

All that being said, I have no complaints at all about your decision of getting rid of the deprecated MPI1 stuff. I do support your move, and I updated mpi4py accordingly. Moreover, I got rid myself of MPI1 stuff years ago in favor of the MPI2 APIs, but had to keep the dependency on MPI_LB/UB around for the very unlikely case someone REALLY wanted to build with a legacy MPI1 implementations, or had Python code using MPI.UB/LB. My complain is just about the "fix" that you implemented in 4.0.1. it is a patch release! You cannot mess with your headers in a patch release. If you made a mistake, well, wait at least for 4.1.0 to fix the mistake. You guys make a great deal of not breaking ABIs, but 4.0.1 broke the API!

And once more, please do not get offended, Open MPI has a tradition of breaking mpi4py release after release, I have tons of tests flagged as know failures for specific Open MPI versions. Things have improve a lot since 2.0.0, but now it happened again. It is probably the only third-party code in the world that exercises almost all of the MPI API in a single mpiexec run. Long ago I argued that mpi4py should be used in your own CI infrastructure. A member of your team argued that Open MPI may not be interested in getting test failures out mpi4py bugs. Well, this is issue 121, and the initial commit is 2008. If you go through all of these issue repores, you will find no more than 3 or 4 instances of actual mpi4py bugs, all the rest are questions, build issues, and runtime failures out of problems elsewhere.

[Jeff Squyres]

@dalcinl You are absolutely correct: we screwed up in v4.0.0. No offense taken at all -- it was our mistake.

I feel your pain about supporting MPI implementations; I was actually in the same situation back in my grad school days (I supported both OOMPI and the implementation-neutral C++ bindings, and that was back in the days when there were a bunch of different MPI implementations, not just 2 main families [Open MPI and MPICH]).

You're totally right, of course: we need to get mpi4py in our CI infrastructure. It is on my to-do list (you+us talked about this fairly recently -- perhaps this past December?), and it has unfortunately not yet bubbled up to the top of my priority list yet.