It makes sense - but isn’t it slurm that is linking libpmi against libslurm? I don’t think we are making that connection, so it would be a slurm issue to change it.
> On Jan 28, 2016, at 10:12 PM, William Law <willthe...@gmail.com> wrote: > > Hi, > > Our group can't find anyway to do this and it'd be helpful. > > We use slurm and keep upgrading the slurm environment. OpenMPI bombs out > against PMI each time the libslurm stuff changes, which seems to be fairly > regularly. Is there a way to compile against slurm but insulate ourselves > from the libslurm chaos? Obvious will ask the slurm folks too. > > [wlaw@some-node /scratch/users/wlaw/imb/src]$ mpirun -n 2 --mca grpcomm ^pmi > ./IMB-MPI1 > [some-node.local:42584] mca: base: component_find: unable to open > /share/sw/free/openmpi/1.6.5/intel/13sp1up1/lib/openmpi/mca_ess_pmi: > libslurm.so.28: cannot open shared object file: No such file or directory > (ignored) > [some-node.local:42585] mca: base: component_find: unable to open > /share/sw/free/openmpi/1.6.5/intel/13sp1up1/lib/openmpi/mca_pubsub_pmi: > libslurm.so.28: cannot open shared object file: No such file or directory > (ignored) > [some-node.local:42586] mca: base: component_find: unable to open > /share/sw/free/openmpi/1.6.5/intel/13sp1up1/lib/openmpi/mca_pubsub_pmi: > libslurm.so.28: cannot open shared object file: No such file or directory > (ignored) > > (sent it via the wrong email so it bounced..... heh) > > Upon further investigation it seems like the most appropriate thing would be > to point it at compile time to libslurm.so instead of libslurm.so.xx; does > that make sense? > > Thanks, > > Will > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/01/28408.php
