The -x option only applies to your application processes - it is never
applied to the OMPI processes such as the OMPI daemons (orteds). If
you built OMPI with the Intel library, then trying to pass the path to
libimf via -x will fail - your application processes will get that
library path,
mpirun -x LD_LIBRARY_PATH -host tya64 connectivity_c
complained about libimf.so (not found), just the same as without "-x
LD_LIBRARY_PATH" (tried to give the full path to the PATH with same
error)
while
# dpkg --search libimf.so
/opt/intel/fce/10.1.022/lib/libimf.so
/opt/intel/fce/10.1.022/lib/l
If you want to find libimf.so, which is a shared INTEL library,
pass the library path with a -x on mpirun
mpirun -x LD_LIBRARY_PATH
DM
On Fri, 10 Apr 2009, Francesco Pietra wrote:
Hi Gus:
If you feel that the observations below are not relevant to openmpi,
please disregard the mes
Hi Gus:
If you feel that the observations below are not relevant to openmpi,
please disregard the message. You have already kindly devoted so much
time to my problems.
The "limits.h" issue is solved with 10.1.022 intel compilers: as I
felt, the problem was with the pre-10.1.021 version of the int
Hi Francesco
Francesco Pietra wrote:
Hi:
As failure to find "limits.h" in my attempted compilations of Amber of
th fast few days (amd64 lenny, openmpi 1.3.1, intel compilers
10.1.015) is probably (or I hope so) a bug of the version used of
intel compilers (I made with debian the same observation
Hi:
As failure to find "limits.h" in my attempted compilations of Amber of
th fast few days (amd64 lenny, openmpi 1.3.1, intel compilers
10.1.015) is probably (or I hope so) a bug of the version used of
intel compilers (I made with debian the same observations reported
for gentoo,
http://software.
