Here’s something even weirder. You cannot build that file unless mpi.h already exists, which it won’t until you build the MPI layer. So apparently what is happening is that we somehow pickup a pre-existing version of mpi.h and use that to build the file?
Checking around, I find that all my available machines have an mpi.h somewhere in the default path because we always install _something_. I wonder if our master would fail in a distro that didn’t have an MPI installed... > On Jun 22, 2017, at 5:02 PM, r...@open-mpi.org wrote: > > It apparently did come in that way. We just never test -no-ompi and so it > wasn’t discovered until a downstream project tried to update. Then...boom. > > >> On Jun 22, 2017, at 4:07 PM, Barrett, Brian via devel >> <devel@lists.open-mpi.org> wrote: >> >> I’m confused; looking at history, there’s never been a time when >> opal/util/info.c hasn’t included mpi.h. That seems odd, but so does info >> being in opal. >> >> Brian >> >>> On Jun 22, 2017, at 3:46 PM, r...@open-mpi.org wrote: >>> >>> I don’t understand what someone was thinking, but you CANNOT #include >>> “mpi.h” in opal/util/info.c. It has broken pretty much every downstream >>> project. >>> >>> Please fix this! >>> Ralph >>> >>> _______________________________________________ >>> devel mailing list >>> devel@lists.open-mpi.org >>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >> >> _______________________________________________ >> devel mailing list >> devel@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
