------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-plasma-systemd_20180328-181735 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.0 * Available Python interpreters, in order of preference: [1] python3.5 [2] python2.7 (fallback) [3] jython2.7 (fallback) Available Ruby profiles: [1] ruby22 (with Rubygems) [2] ruby23 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.7.0 [icedtea-bin-8] 2) JamVM JDK 2.0.0 [jamvm] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm [2] jamvm emerge -qpv sys-cluster/pmix [ebuild N ] sys-cluster/pmix-2.1.1 USE="munge -debug -pmi"
Created attachment 526550 [details] emerge-info.txt
Created attachment 526552 [details] emerge-history.txt
Created attachment 526554 [details] etc.portage.tbz2
Created attachment 526556 [details] logs.tbz2
Created attachment 526558 [details] sys-cluster:pmix-2.1.1:20180404-013731.log
Looks like jlec just recently added this. It's been internally packaged in openmpi since at least the 2.0.0 release. With 3.0.0, openmpi updated it's internal copy to 2.1.0, so I can just update the dependency there and have openmpi use the new package (assuming 2.1.1 is just a patch release). For older openmpi versions, I suggest we just create blockers (they all used <=pmix-1.2.5) in order to avoid complexity. jlec, that work for you?
Open MPI configure has --with-pmix=external option. I've managed to build sys-cluster/openmpi-3.1.1 for ABI_X86="64 -32 -x32" (pmix isn't multilib) with this change: --- /usr/portage/sys-cluster/openmpi/openmpi-3.1.1.ebuild 2018-07-02 20:09:21.000000000 +0300 +++ /usr/portage/sys-cluster/openmpi/openmpi-3.1.1.ebuild 2018-07-09 01:26:47.037477263 +0300 @@ -48,7 +48,7 @@ !sys-cluster/mpich2 !sys-cluster/nullmpi !sys-cluster/mpiexec - !sys-cluster/pmix + sys-cluster/pmix >=dev-libs/libevent-2.0.22[${MULTILIB_USEDEP},threads] dev-libs/libltdl:0[${MULTILIB_USEDEP}] >=sys-apps/hwloc-1.11.2[${MULTILIB_USEDEP},numa?] @@ -109,6 +109,7 @@ --with-libltdl="${EPREFIX}/usr" \ --with-libevent="${EPREFIX}/usr" \ --enable-mpi-fortran=$(usex fortran all no) \ + $(multilib_native_with pmix external) \ $(use_enable cxx mpi-cxx) \ $(use_with cma) \ $(use_with cuda cuda "${EPREFIX}"/opt/cuda) \
How is it going? Did this info helped?: (In reply to silver_ghost from comment #7) > Open MPI configure has --with-pmix=external option. I've managed to build > .....
Am I right that pmix should have multilib support if openmpi does?
(In reply to silver_ghost from comment #8) > How is it going? Did this info helped?: > (In reply to silver_ghost from comment #7) > > Open MPI configure has --with-pmix=external option. I've managed to build > > ..... That doesn't help as we need multilib support all the way down the pmix deptree. Which means, pending interest from others to do some of that work, this blocker is probably going to stay around for a while.
(In reply to Justin Bronder from comment #10) > That doesn't help as we need multilib support all the way down the pmix > deptree. Which means, pending interest from others to do some of that work, > this blocker is probably going to stay around for a while. I'm trying to do this. I've managed to build sys-cluster/pmix[-debug -munge -pmi] for now. ABI_X86="32 64".
