Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

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- options, Open MPI will, by default, search for header

Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

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

Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

On Nov 29, 2017, at 4:51 PM, Vanzo, Davide wrote: > > 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,

Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

Jeff, Thanks for your feedback. Although tempting, changing the version of OpenMPI would mean a significant amount of changes in our software stack. Hence I would like to find out what the problem is and hopefully its solution. Where is the -L/usr/lib64 injected? Is there a way to patch the

Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

FWIW, adding -L/usr/lib or -L/usr/lib64 is generally considered Bad, because it may usurp the default linker path order. I note that you're using Open MPI 1.10.3 -- if you're unwilling/unable to upgrade to Open MPI 3.0.x, could you upgrade to Open MPI 1.10.7? We may well have fixed the issue

Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

Thank you Åke, Reuti and Thomas for your replies. Just to clarify. The reason why /usr/lib64/libgfortran.so does not exist is intentional because on our cluster we use a minimal CentOS installation and all libraries are provided through the software stack built via EasyBuild on a non-system

Re: [OMPI users] OMPI 2.1.2 and SLURM compatibility

Hi Bennet I suspect the problem here lies in the slurm PMIx plugin. Slurm 17.11 supports PMIx v2.0 as well as (I believe) PMIx v1.2. I’m not sure if slurm is somehow finding one of those on your system and building the plugin or not, but it looks like OMPI is picking up signs of PMIx being

Re: [hwloc-users] How are processor groups under Windows reported?

Hello Brice, That makes perfect sense, and yes I do see group objects on larger systems. I was hoping to use the number of groups to see if it was safe to call hwloc_set_proc_cpubind(), but I obviously can't. I can of course simply call the Windows GetActiveProcessorGroupCount() function

Re: [hwloc-users] How are processor groups under Windows reported?

Hello We only add hwloc Group objects when necessary. On your system, each processor group contains a single NUMA node, so these Groups would not really bring additional information about the hierarchy of resources. If you had a bigger system with, let's say, 4 NUMA nodes, with 2 of them in each

[hwloc-users] How are processor groups under Windows reported?

Hello, Thank you to all contributors to hwloc - very useful. In the FAQ,  under the section "What are these Group objects in my topology?" it says that they are used for "Windows processor groups". However, I'm either not seeing this, or I'm looking in the wrong place. On a system with two

Re: [OMPI users] mpifort cannot find libgfortran.so at the correct path

Hello Davide, On 11/28/17 15:58, Vanzo, Davide wrote: I am having a very weird problem with mpifort that I cannot understand. I am building OpenMPI 1.10.3 with GCC 5.4.0 with EasyBuild and everything goes fine until I try to use mpifort to build any MPI Fortran code, which fails with the