Hi,
> Am 28.11.2017 um 15:58 schrieb Vanzo, Davide :
>
> Hello all,
> 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
>
> Am 28.11.2017 um 17:19 schrieb Reuti :
>
> Hi,
>
>> Am 28.11.2017 um 15:58 schrieb Vanzo, Davide :
>>
>> Hello all,
>> 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
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 error
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 pat
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 i
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 co
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,
I'm assuming -- I haven't te
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 ev
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 file
Jeff,
I have to resuscitate this thread since the issue is still there even on
version 2.1.1.
I have also tried with --with-pmi without a path, but the -L/usr/lib64 is still
added to the wrapper. If I do not add it at all, then launching an MPI
application with srun will not work.
What would you
Davide,
That is the consequence of an Open MPI bug in the PMI detection.
For the time being, you can use the attached patch (not a final one though)
Note you need to have recent autotools installed, and then you will have to
autogen.sh --force
before rebuilding Open MPI
Cheers,
Gilles
11 matches
Mail list logo
