You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the binaries currently created as part of the PRRTe build will still be needed by Open MPI. However, we don't want to have names which conflict with an external PRRTe installation.
Rather than renaming the binaries, a better approach may be to use some kind of name prefixing mechanism. This would require enhancements to the PRRTE configury and Makefiles. There would also need to be c source code changes.
Ultimately we may wish to use a reduced set of tools, particularly for distributed virtual machine (DVM) management.
Note changes will need to be made to the Open MPI source code itself to so that its mpirun command continues to work. In particular ocurrences of prterun will need to be updated. Eventually these changes will be superseded by work done for issue open-mpi/ompi#12712.
To continue supporting singleton spawn within OMPI - which invokes prte currently, the code in will need to be checked and possibly modified - ompi/dpm/dpm.c.
Renaming of prted will involve updating several places in the PRRTE PLM framework as well.
In addition to the binaries, the libprrte.so library installed as part of the build process should be prefixable as well. This will provide for additional protection for the renamed binaries not accidentally picking up an external libprrte.so at runtime. This rename should also change the soname of the library as well. This change is being tracked by issue #15 .
Ideally, the documentation pertaining to these binaries would also be updated to reflect the name changes resulting from the prefixing mechanism.
The text was updated successfully, but these errors were encountered:
Technically, the only binaries you need for OMPI are prte (which is your mpirun) and prted. It would probably be a mistake for you to retain DVM operations in your fork as that will result in conflicts with true PRRTE installations.
prterun is just a symlink to prte, so if you update your mpirun to execute prte, you don't need to retain it.
Renaming these binaries is opening a giant can of worms - I would strongly advise against it.
hppritcha
changed the title
rename all prrte related binaries that will be used by Open MPI
Add prefixing capability to prrte rbinaries and libraries that will be used by Open MPI
Aug 21, 2024
hppritcha
changed the title
Add prefixing capability to prrte rbinaries and libraries that will be used by Open MPI
Add prefixing capability to prrte binaries that will be used by Open MPI
Aug 21, 2024
Some of the binaries currently created as part of the PRRTe build will still be needed by Open MPI. However, we don't want to have names which conflict with an external PRRTe installation.
The binaries that need to be renamed are
Rather than renaming the binaries, a better approach may be to use some kind of name prefixing mechanism. This would require enhancements to the PRRTE configury and Makefiles. There would also need to be c source code changes.
Ultimately we may wish to use a reduced set of tools, particularly for distributed virtual machine (DVM) management.
Note changes will need to be made to the Open MPI source code itself to so that its
mpirun
command continues to work. In particular ocurrences ofprterun
will need to be updated. Eventually these changes will be superseded by work done for issue open-mpi/ompi#12712.To continue supporting singleton spawn within OMPI - which invokes
prte
currently, the code in will need to be checked and possibly modified - ompi/dpm/dpm.c.Renaming of
prted
will involve updating several places in the PRRTE PLM framework as well.In addition to the binaries, the libprrte.so library installed as part of the build process should be prefixable as well. This will provide for additional protection for the renamed binaries not accidentally picking up an external libprrte.so at runtime. This rename should also change the soname of the library as well. This change is being tracked by issue #15 .
Ideally, the documentation pertaining to these binaries would also be updated to reflect the name changes resulting from the prefixing mechanism.
The text was updated successfully, but these errors were encountered: