-
Notifications
You must be signed in to change notification settings - Fork 901
developers: Doc how to build against external PMIx/PRTE #12946
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,9 +1,87 @@ | ||
Building Open MPI | ||
================= | ||
|
||
General | ||
------- | ||
|
||
Once you have run ``autogen.pl`` successfully, you can configure and | ||
build Open MPI just like end users do with official distribution Open | ||
MPI tarballs. | ||
|
||
See the :doc:`general "Install Open MPI" documentation for more | ||
details. </installing-open-mpi/index>` | ||
|
||
Building Against External OpenPMIx / PRRTE | ||
------------------------------------------ | ||
|
||
One thing that developers and/or packagers may need to do is to build | ||
Open MPI against an external OpenPMIx and/or PRRTE source tree (i.e., | ||
an OpenPMIx and/or PRRTE installation that was not built from the | ||
embedded copies inside the Open MPI source tree / Git submodules). | ||
|
||
With regards to :doc:`Open MPI's required dependent libraries | ||
</installing-open-mpi/required-support-libraries>` (Hwloc, Libevent, | ||
OpenPMIx, and PRRTE), it generally is simplest to build Open MPI in | ||
one of two ways: | ||
|
||
#. Build and use all the **internal** copies of Open MPI's required | ||
dependent libraries. | ||
|
||
* Specifically: use the Hwloc, Libevent, OpenPMIx, and PRRTE source | ||
trees that are bundled in with Open MPI's source code. | ||
|
||
#. Build and use all **external** copies of Open MPI's required | ||
dependent libraries. | ||
|
||
* Specifically: ignore the Hwloc, Libevent, OpenPMIx, and PRRTE source | ||
trees that are bundled in with Open MPI's source code, and, | ||
instead, compile and link Open MPI against already-installed | ||
versions of these libraries. | ||
|
||
Other variations are possible, but can get tricky and complicated with | ||
subtle linker consequences, and are therefore not recommended. | ||
|
||
Some facts that are relevant to know when building against an external | ||
OpenPMIx / PRRTE: | ||
|
||
1. Open MPI, OpenPMIx, and PRRTE must all be built against the | ||
**same** installation of Hwloc and Libevent. Meaning: | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not fully correct - PRRTE doesn't need to have the same. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You can (will) run into super weird errors if PMIx, PRTE, and/or Open MPI are using different libevents and/or hwlocs at run-time. They should be completely orthogonal, but we have definitely seen cases where they are not. I'm ok documenting it as a must even if there are some cases where it actually does work to -- for example -- have PMIx run-time link against hwloc version X and PRTE run-time link against hwloc version Y. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is where you are getting into trouble. Whatever PMIx PRRTE is using, that PMIx and PRRTE must use the same hwloc and libevent. However, as I said elsewhere, there is no requirement that PRRTE and OMPI use the same PMIx. So there is no transitive property involved here - there is a complete airbreak between PRRTE and OMPI. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, so something like:
|
||
* Assumedly the external OpenPMIx and PRRTE were built against | ||
external Hwloc and Libevent. Open MPI **must** compile and link | ||
against the **same** Hwloc and Libevent that the external | ||
OpenPMIx and PRRTE were built against. | ||
|
||
.. admonition:: Critical | ||
:class: Danger | ||
|
||
Open MPI, OpenPMIx, and PRRTE must all use the same Hwloc and | ||
Libevent libraries at run time (e.g., they must all resolve to | ||
the same run-time loadable libraries at run time). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not totally correct - PRRTE doesn't have to use the same as OMPI never loads "libprrte", so there is no potential for confusion. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By transitive property, though, isn't this true? OMPI must use the same hwloc + libevent as PMIX, and PRTE must use the same hwloc + libevent as PMIx, so therefore don't they all have to be the same? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you can have two versions of PMIx installed. I don't think this is super common for a developer, but given how Slurm is packaged, may be more common there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. PBS does it too now - in fact, they include PRRTE and PMIx, so not uncommon to see multiple installs there. |
||
|
||
.. important:: This statement applies regardless of whether | ||
Open MPI -- and/or the other libraries -- are | ||
built as static or dynamically-loadable | ||
libraries. | ||
|
||
* Unless you really know what you are doing, this usually means | ||
building and installing Open MPI against the same installation | ||
tree(s) of Hwloc and Libevent that OpenPMIx and PRRTE used to | ||
build themselves. | ||
|
||
For example, consider an environment where you install Hwloc, | ||
Libevent, OpenPMIx, and PRRTE via the operating system's package | ||
manager. Assuming that the package-manager installs of OpenPMIx | ||
and PRRTE were built against the package-manager-provider Hwloc | ||
and Libevent, then Open MPI will *also* need to be built against | ||
the package-manager-provided Hwloc and Libevent. To build Open | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, true for PMIx but not for PRRTE |
||
MPI this way, you may need to install the package manager's | ||
"developer" Hwloc, Libevent, OpenPMIx, and/or PRRTE packages. | ||
|
||
1. Open MPI and PRRTE must be built against the **same** installation | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, not true - PMIx is designed to handle cross-version messaging. Only issue would be ensuring that the PMIx being used by PRRTE is new enough to support any OMPI-used features. Given the minimums we set, that shouldn't be a problem. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, fair point here. I was really thinking about Hwloc and Libevent when I was writing this bullet. I'll update. |
||
of OpenPMIx. | ||
|
||
.. important:: Similar to how OpenPMIx, PRRTE, and Open MPI, must | ||
be built against the same Hwloc and Libevent, PRRTE | ||
and Open MPI must be built against the same | ||
OpenPMIx. |
Uh oh!
There was an error while loading. Please reload this page.