Doug Ledford <dledford@xxxxxxxxxx> writes: > There was a changeover in maintainership for this package internally, so > I'm coming into this issue cold. Thanks for responding. (I assume that means the Red Hat openmpi package.) I wasn't expecting to get it sorted out in RHEL, and wanted to avoid what looks like being mess in EPEL. > My apologies for that. Have you > installed the compat-openmpi package and do things still break with that > installed (at least for openmpi, mpich is another matter entirely)? Yes, but it's v 1.4. It clearly doesn't allow packages built against 1.6 to install, and it's not a dependency of openmpi-1.8. I don't now have the test installation I used earlier, but the following is on a production system which uses a self-built 1.6 package as a compatible upgrade from 1.5 versus a rebuilt Fedora 1.8, modified to install in parallel. The program was built against 1.6. $ rpm -q compat-openmpi compat-openmpi-1.4.3-1.2.el6.x86_64 $ ldd mpi-hello | grep libmpi_f libmpi_f90.so.1 => /usr/lib64/openmpi/lib/libmpi_f90.so.1 (0x00007fb261161000) libmpi_f77.so.1 => /usr/lib64/openmpi/lib/libmpi_f77.so.1 (0x00007fb260f2d000) $ module switch openmpi-x86_64 mpi/openmpi_18-x86_64 $ ldd mpi-hello | grep libmpi_f libmpi_f90.so.1 => not found libmpi_f77.so.1 => not found I'm not actually interested in mpich, other than for packaging things according to Fedora guidelines, so I can't say much about that, other than it won't upgrade either. We have mvapich for occasional use with MPI_THREAD_MULTIPLE, but the current version seems compatible with the one package I've built against mvapich. > The other alternative (although not a good one for EL6, but could be > used in EL7 and I believe is what's used in Fedora, although it's been a > long while since I help define the Fedora MPI policies so I could be > wrong) would be to make multiple versions of openmpi install side by > side without ever doing an upgrade. The policy appears to allow that if you abuse the compiler variable as a version (as above) though you have to fix the spec file more than that. > Then newer openmpi releases would, > at most, change the default environment but leave the older environment > selectable via modules, allowing a user to simply select the old > environment and keep on running. The reason you might want a (modified) 1.5/6 and a 1.8 anyhow is that 1.8 has lost checkpointing, at least, while gaining things like apparently-better mpi-io, which would be of interest if I was allowed to run pvfs. I'd guess most sites won't run vanilla openmpi packages, but still want to install packages built against them (at least what seems to be the minority which believe in packaging). I must say I don't understand why these changes were made, let alone not documented. It's not just linking/dependencies, but more which is affected at runtime <https://bugzilla.redhat.com/show_bug.cgi?id=1158864>. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
