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

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

2018-02-22 Thread Gilles Gouaillardet


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


On 2/23/2018 2:42 AM, Vanzo, Davide wrote:

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 suggest to try?
--
*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:25:16-06:00 Vanzo, Davide 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 
amp;lt;davide.va...@vanderbilt.eduamp;gt; wrote:
amp;amp;gt;
amp;amp;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.

amp;amp;gt; Hence I would like to find out what the problem is and 
hopefully its solution.
amp;amp;gt;
amp;amp;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%2Fusersamp;amp;amp;data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C11f5b064a08144e0e4bc08d5377584eb%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C636475900235203296amp;amp;amp;sdata=O94%2FKc7jajpw5%2BdCuRxvkjrdoR9ESR0DLB61C30%2BBp0%3Damp;amp;amp;reserved=0
amp;lt;/davide.va...@vanderbilt.eduamp;gt;



___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users


diff --git a/config/opal_check_pmi.m4 b/config/opal_check_pmi.m4
index dee6d94..fb05ca6 100644
--- a/config/opal_check_pmi.m4
+++ b/config/opal_check_pmi.m4
@@ -174,10 +174,10 @@ AC_DEFUN([OPAL_CHECK_PMI],[
   [opal_enable_pmi1=no])
 
AS_IF([test "$opal_enable_pmi1" = "yes"],
- [AS_IF([test "$default_pmi_loc" = "no" || test 
"$slurm_pmi_found" = "yes"],
+ [AS_IF([test "$slurm_pmi_found" = "yes"],
[opal_pmi1_CPPFLAGS="$pmi_CPPFLAGS"
  AC_SUBST(opal_pmi1_CPPFLAGS)])
-  AS_IF([test "$default_pmi_libloc" = "no" || test 
"$slurm_pmi_found" = "yes"],
+  AS_IF([test "$default_pmi_libloc" = "no" && test 
"$slurm_pmi_found" = "yes"],
[opal_pmi1_LDFLAGS="$pmi_LDFLAGS"
  AC_SUBST(opal_pmi1_LDFLAGS)
  opal_pmi1_rpath="$pmi_rpath"
@@ -195,10 +195,10 @@ AC_DEFUN([OPAL_CHECK_PMI],[

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

2018-02-22 Thread Vanzo, Davide

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 suggest to try?

--
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:25:16-06:00 Vanzo, Davide 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.

On 2017-11-29 16:07:04-06:00 Jeff Squyres (jsquyres) wrote:

On Nov 29, 2017, at 4:51 PM, Vanzo, Davide
amp;lt;davide.va...@vanderbilt.eduamp;gt; wrote:
amp;amp;gt;
amp;amp;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.

amp;amp;gt; Hence I would like to find out what the problem is and
hopefully its solution.
amp;amp;gt;
amp;amp;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%2Fusersamp;amp;amp;data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C11f5b064a08144e0e4bc08d5377584eb%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C636475900235203296amp;amp;amp;sdata=O94%2FKc7jajpw5%2BdCuRxvkjrdoR9ESR0DLB61C30%2BBp0%3Damp;amp;amp;reserved=0
amp;lt;/davide.va...@vanderbilt.eduamp;gt;
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users

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

2017-11-29 Thread Jeff Squyres (jsquyres)

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 files and/or libraries for .  If
the relevant files are found, Open MPI will built support for ;
if they are not found, Open MPI will skip building support for .
However, if you specify --with- on the configure command line and
Open MPI is unable to find relevant support for , 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  
> 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%2Fusersamp;data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C11f5b064a08144e0e4bc08d5377584eb%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C636475900235203296amp;sdata=O94%2FKc7jajpw5%2BdCuRxvkjrdoR9ESR0DLB61C30%2BBp0%3Damp;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

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

2017-11-29 Thread Vanzo, Davide

Jeff,

Thanks for pointing me in the right direction. I have finally figured out what
the problem is.

And the reason why in the other system I tested the build it was working is
because there is no Slurm installed in it.

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.

--
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%2Fusersamp;data=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C11f5b064a08144e0e4bc08d5377584eb%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C636475900235203296amp;sdata=O94%2FKc7jajpw5%2BdCuRxvkjrdoR9ESR0DLB61C30%2BBp0%3Damp;reserved=0
/davide.va...@vanderbilt.edu
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users

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

2017-11-29 Thread Jeff Squyres (jsquyres)

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 tested myself -- this -L issue).  Hypothetically, it 
should be a fairly painless upgrade.

> 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 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://lists.open-mpi.org/mailman/listinfo/users

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

2017-11-29 Thread Vanzo, Davide

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 code so that it 
does not get added to the list of options to gfortran?


--
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 14:31:48-06:00 Jeff Squyres (jsquyres) wrote:

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 in that time (i.e., do not have mpifort add -L/usr/lib64 
to the command line).


gt; On Nov 29, 2017, at 11:30 AM, Vanzo, Davide 
davide.va...@vanderbilt.edu wrote:
gt;
gt; Thank you Åke, Reuti and Thomas for your replies.
gt;
gt; 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 path.
gt;
gt; The output of `mpifort -show` shows the correct executable for 
`gfortran` ( I checked with `which gfortran`):
gt;
gt; $ mpifort multitask_mpi.f90 -show
gt; gfortran multitask_mpi.f90 
-I/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/include 
-I/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
-L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath 
-Wl,/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
-Wl,--enable-new-dtags 
-L/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
gt;
gt;
gt; If I try to compile the source code with the explicit command after 
removing the `-L/usr/lib64` flag it compiles, links and executes correctly.
gt;
gt; For the sake of testing I have built OpenMPI in the same exact way on 
another machine with the same minimal OS. The only difference (at least that I 
am aware of) is the root prefix of the installation path. In this case it works 
correctly even without removing `-L/usr/lib64`.
gt;
gt; To try to better understand, I have launched `mpifort -v`. Below you 
can find the paths in COMPILER_PATH and LIBRARY_PATH for both systems.
gt; Take into account that on the broken system `/accre/arch` is a symlink 
to `/gpfs22/accre/optimized/haswell`. But I do not see how this can be the 
problem...
gt;
gt;
gt; Working system:
gt;
gt; COMPILER_PATH
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/
gt;
gt; LIBRARY_PATH
gt; /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/../lib64/
gt; /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/../lib64/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../lib64/
gt; /lib/../lib64/
gt; /usr/lib/../lib64/
gt; 
/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib/
gt; 
/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/hwloc/1.11.3/lib/
gt; 
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/numactl/2.0.11/lib/
gt; 
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/lib/
gt; /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/
gt; /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/
gt; 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../
gt; /lib/
gt; /usr/lib/
gt;
gt;
gt; Broken system:
gt;
gt; COMPILER_PATH
gt; 
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
gt; 
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../libexec/gcc/
gt;
gt; LIBRARY_PATH
gt; 
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
gt; 
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/
gt; /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/../lib64/
gt;

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

2017-11-29 Thread Jeff Squyres (jsquyres)

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 in that time (i.e., do not have mpifort add -L/usr/lib64 
to the command line).


> On Nov 29, 2017, at 11:30 AM, Vanzo, Davide  
> wrote:
> 
> 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 path.
> 
> The output of `mpifort -show` shows the correct executable for `gfortran` ( I 
> checked with `which gfortran`):
> 
> $ mpifort multitask_mpi.f90 -show
> gfortran multitask_mpi.f90 
> -I/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/include
>  -I/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
> -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath 
> -Wl,/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
> -Wl,--enable-new-dtags 
> -L/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
> -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
> 
> 
> If I try to compile the source code with the explicit command after removing 
> the `-L/usr/lib64` flag it compiles, links and executes correctly.
> 
> For the sake of testing I have built OpenMPI in the same exact way on another 
> machine with the same minimal OS. The only difference (at least that I am 
> aware of) is the root prefix of the installation path. In this case it works 
> correctly even without removing `-L/usr/lib64`.
> 
> To try to better understand, I have launched `mpifort -v`. Below you can find 
> the paths in COMPILER_PATH and LIBRARY_PATH for both systems.
> Take into account that on the broken system `/accre/arch` is a symlink to 
> `/gpfs22/accre/optimized/haswell`. But I do not see how this can be the 
> problem...
> 
> 
> Working system:
> 
> COMPILER_PATH
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/
> 
> LIBRARY_PATH
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/../lib64/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/../lib64/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../lib64/
> /lib/../lib64/
> /usr/lib/../lib64/
> /accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib/
> /accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/hwloc/1.11.3/lib/
> /accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/numactl/2.0.11/lib/
> /accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/lib/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../
> /lib/
> /usr/lib/
> 
>  
> Broken system:
> 
> COMPILER_PATH
> /gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
> /gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../libexec/gcc/
> 
> LIBRARY_PATH
> /gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
> /gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/../lib64/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/../lib64/
> /gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../lib64/
> /lib/../lib64/
> /usr/lib/../lib64/
> /accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib/
> /accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/hwloc/1.11.3/lib/
> /accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/numactl/2.0.11/lib/
> /accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/lib/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/
> /gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../
> /lib/
> /usr/lib/
> 
> 
>  
> --

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

2017-11-29 Thread Vanzo, Davide

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 path.

The output of `mpifort -show` shows the correct executable for `gfortran` ( I 
checked with `which gfortran`):

$ mpifort multitask_mpi.f90 -show
gfortran multitask_mpi.f90 
-I/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/include 
-I/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
-L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath 
-Wl,/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
-Wl,--enable-new-dtags 
-L/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib 
-lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi


If I try to compile the source code with the explicit command after removing 
the `-L/usr/lib64` flag it compiles, links and executes correctly.

For the sake of testing I have built OpenMPI in the same exact way on another 
machine with the same minimal OS. The only difference (at least that I am aware 
of) is the root prefix of the installation path. In this case it works 
correctly even without removing `-L/usr/lib64`.

To try to better understand, I have launched `mpifort -v`. Below you can find 
the paths in COMPILER_PATH and LIBRARY_PATH for both systems.
Take into account that on the broken system `/accre/arch` is a symlink to 
`/gpfs22/accre/optimized/haswell`. But I do not see how this can be the 
problem...


Working system:

COMPILER_PATH
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/

LIBRARY_PATH
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/../lib64/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/../lib64/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../lib64/
/lib/../lib64/
/usr/lib/../lib64/
/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib/
/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/hwloc/1.11.3/lib/
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/numactl/2.0.11/lib/
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/lib/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../
/lib/
/usr/lib/


Broken system:

COMPILER_PATH
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.4.0/
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../libexec/gcc/

LIBRARY_PATH
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/../lib64/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/../lib64/
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../lib64/
/lib/../lib64/
/usr/lib/../lib64/
/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/OpenMPI/1.10.3/lib/
/accre/arch/easybuild/software/Compiler/GCC/5.4.0-2.26/hwloc/1.11.3/lib/
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/numactl/2.0.11/lib/
/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/lib/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib/
/gpfs22/accre/optimized/haswell/easybuild/software/Core/GCCcore/5.4.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../
/lib/
/usr/lib/



--
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

___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users

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

2017-11-29 Thread Thomas Jahns


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 log you see below.
The thing I do not understand is why the linker searches for libgfortran.so in 
/usr/lib64 instead of the actual GCC installation path,  where the file is 
actually located. Both LD_LIBRARY_PATH and LIBRARY_PATH contain the correct path 
to the library. The gfortran compiler works correctly for compiling serial code.

Attached you can also find the ourput of the same command with LD_DEBUG=1.
Any idea what is going wrong?


The place the link-time link editor ld searches for still seems to be /usr/lib64 
first.



$ ll /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/libgfortran.so
lrwxrwxrwx 1 buildbot buildbot 20 Nov 27 18:44 
/accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/libgfortran.so -> 
libgfortran.so.3.0.0


So I assume you mean to invoke a gfortran binary located at

/accre/arch/easybuild/software/Core/GCCcore/5.4.0/bin/gfortran

?


$ mpifort multitask_mpi.f90


What does "mpifort -show" report what gfortran command is used? If the first 
part is simply gfortran, what does "which gfortran" print?


/accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/bin/ld.gold: 
error: cannot open /usr/lib64/libgfortran.so: No such file or directory


so obviously your build finds something named libgfortran.so in /usr/lib64 but 
cannot use it. Is it a defunct symbolic link?



/tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined  > 
reference to '_gfortran_date_and_time'

[...]
These are just followup errors from not being able to find the correct 
libgfortran.

Regards, Thomas




smime.p7s
Description: S/MIME Cryptographic Signature
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users

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

2017-11-28 Thread 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 to use mpifort to build any MPI Fortran code, which 
> fails with the error log you see below. 
> The thing I do not understand is why the linker searches for libgfortran.so 
> in /usr/lib64 instead of the actual GCC installation path,  where the file is 
> actually located. Both LD_LIBRARY_PATH and LIBRARY_PATH contain the correct 
> path to the library. The gfortran compiler works correctly for compiling 
> serial code.
> Attached you can also find the ourput of the same command with LD_DEBUG=1.
> Any idea what is going wrong?

Although 1.10.3 is outdated and the use of a newer Open MPI version advisable, 
the culprit seems to lie in:

> cannot open /usr/lib64/libgfortran.so: No such file or directory

Does this symbolic link exist? Does it point to your installed one too?

Maybe the developer package of GCC 5.4.0 is missing. Hence it looks for 
libgfortran.so somewhere else and finds only a broken symbolic link.

-- Reuti


> Thank you for your help!
>  
> $ ll /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/libgfortran.so
> lrwxrwxrwx 1 buildbot buildbot 20 Nov 27 18:44 
> /accre/arch/easybuild/software/Core/GCCcore/5.4.0/lib64/libgfortran.so -> 
> libgfortran.so.3.0.0
>  
> $ mpifort multitask_mpi.f90 
> /accre/arch/easybuild/software/Compiler/GCCcore/5.4.0/binutils/2.26/bin/ld.gold:
>  error: cannot open /usr/lib64/libgfortran.so: No such file or directory
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_date_and_time'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_st_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_integer_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_string_trim'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_character_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_integer_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_integer_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_character_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_integer_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_character_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_transfer_character_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_string_trim'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function timestamp_: error: undefined 
> reference to '_gfortran_st_write_done'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
> undefined reference to '_gfortran_st_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
> undefined reference to '_gfortran_st_write_done'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
> undefined reference to '_gfortran_st_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
> undefined reference to '_gfortran_st_write_done'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
> undefined reference to '_gfortran_st_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function p0_receive_output_: error: 
> undefined reference to '_gfortran_st_write_done'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_stop_string'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_transfer_real_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_stop_string'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_transfer_real_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_stop_string'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_transfer_real_write'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function MAIN__: error: undefined reference 
> to '_gfortran_stop_string'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function main: error: undefined reference 
> to '_gfortran_set_args'
> /tmp/ccpSxqE6.o:multitask_mpi.f90:function main: error: undefined reference 
> to '_gfortran_set_options'
> collect2:

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

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

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

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

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

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

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

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

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

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

10 matches

Site Navigation

Mail list logo

Footer information