Stefan Brüns writes:
Several programs will end up with implicitly linking to both versions, as libnetcdf and hdf5 use openmpi1 and boost_mpi uses openmpi2. One example is vtk.
This would be a nightmare. As I've stated elsewhere already, I believe it would be better if packages that are used by the 'naive' user - and especially their dependencies - should stay away from using any MPI. I don't see the benefit of MPI if you do not specifically set it up for your task. I will have to look at vtk - tomorrow probably.
As both libraries (libmpi.so.12 and libmpi.so.20) export the same symbols for large parts, this is mayhem waiting to happen.
Yes! I seem to recall that there are tricks that can be done with linker flags - but I'm not even sure if they would help in this case.
For SLE, different MPI versions/implementations are supported using the HPC modules, but for Leap/TW, we should obviously stick with *one* single canonical version.
For Leap we have the same HPC packages available as for SLE. However, these are specifically labled '-hpc' and need to be picked explicitly. They require the use of environment modules - but this should not be a problem as anyone using them will have made a consious choice to use these packages.
Question now, which version to choose?
Apparently, openmpi2 does not work on all architectures (PPC, PPC64BE) [1], and is not supported by some software packages [2].
Are there any drawbacks for using openmpi1 everywhere in TW/Leap 15.x?
Besides the fact that it is unmaintained? We do not provide or support it any more on SLE-15. Right now, openmpi2 is supported there, meaning that all openmpi2 packages on Leap 15(.0) will have the benefit of receiving all the bug fixes we add to SLE.
I have opened a bug report: https://bugzilla.opensuse.org/show_bug.cgi? id=1118861
Thanks! Cheers, Egbert.-- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org