Ah. You might also try just --with-pmi (instead of --with-pmi=/usr). That might avoid adding the errant -L/usr/lib64 to the wrapper data files.
Our configure nomenclature is (from README): ----- Note that for many of Open MPI's --with-<foo> options, Open MPI will, by default, search for header files and/or libraries for <foo>. If the relevant files are found, Open MPI will built support for <foo>; if they are not found, Open MPI will skip building support for <foo>. However, if you specify --with-<foo> on the configure command line and Open MPI is unable to find relevant support for <foo>, configure will assume that it was unable to provide a feature that was specifically requested and will abort so that a human can resolve out the issue. ----- > On Nov 29, 2017, at 5:25 PM, Vanzo, Davide <davide.va...@vanderbilt.edu> > wrote: > > Jeff, > > Thanks for pointing me in the right direction. I have finally figured out > what the problem is. > > On the cluster we install Slurm via RPMs and the PMI/PMI2 libraries are in > /usr/lib64. Hence the -L/usr/lib64 flag is the effect of the --with-pmi=/usr > configure flag. The good thing is that even by omitting it the final binary > is correctly linked to the PMI libraries. > > And the reason why in the other system I tested the build it was working is > because there is no Slurm installed in it. > > -- > Davide Vanzo, PhD > Application Developer > Adjunct Assistant Professor of Chemical and Biomolecular Engineering > Advanced Computing Center for Research and Education (ACCRE) > Vanderbilt University - Hill Center 201 > (615)-875-9137 > www.accre.vanderbilt.edu > > On 2017-11-29 16:07:04-06:00 Jeff Squyres (jsquyres) wrote: > > On Nov 29, 2017, at 4:51 PM, Vanzo, Davide > <davide.va...@vanderbilt.edu> wrote: > &gt; > &gt; Although tempting, changing the version of OpenMPI would mean a > significant amount of changes in our software stack. > > Understood. > > FWIW: the only differences between 1.10.3 and 1.10.7 were bug fixes > (including, I'm assuming -- I haven't tested myself -- this -L issue). > Hypothetically, it should be a fairly painless upgrade. > > &gt; Hence I would like to find out what the problem is and hopefully its > solution. > &gt; > &gt; Where is the -L/usr/lib64 injected? Is there a way to patch the code > so that it does not get added to the list of options to gfortran? > > It's injected pretty deep inside configure. > > We might be able to spelunk through the git logs to find the commit that > fixes this issue and you could apply that as a patch, but it might be easier > to just manually patch up the wrapper compiler data file after the build. > > Specifically, it looks like OMPI 1.10.3 is installing faulty values > $prefix/share/openmpi/*-wrapper-data.txt. You can easily edit these files > directly and remove the erroneous -L/usr/lib64. If you're unable to upgrade > to 1.10.7, patching the installed *-wrapper-data.txt files is probably your > best bet. > > -- > Jeff Squyres > jsquy...@cisco.com > > _______________________________________________ > users mailing list > users@lists.open-mpi.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open-mpi.org%2Fmailman%2Flistinfo%2Fusers&amp;data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C11f5b064a08144e0e4bc08d5377584eb%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C636475900235203296&amp;sdata=O94%2FKc7jajpw5%2BdCuRxvkjrdoR9ESR0DLB61C30%2BBp0%3D&amp;reserved=0 > </davide.va...@vanderbilt.edu> > > _______________________________________________ > users mailing list > users@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/users -- Jeff Squyres jsquy...@cisco.com _______________________________________________ users mailing list users@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/users
