Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: [OMPI users] shared libraries issue compiling 1.3.1/intel 10.1.022
From: Francesco Pietra (chiendarret_at_[hidden])
Date: 2009-04-09 11:31:16


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.intel.com/en-us/forums/intel-c-compiler/topic/59886/).

I made a deb package of 10.1.022, icc and ifort.

./configure CC icc, CXX icp, F77 and FC ifort --with-libnuma=/usr (not
/usr/lib so that the numa.h issue is not raised), "make clean", and
"mak install" gave no error signals. However, the compilation tests in
the examples did not pass and I really don't understand why.

The error, with both connectivity_c and hello_c (I was operating on
the parallel computer deb64 directly and have access to everything
there) was failure to find a shared library, libimf.so

# dpkg --search libimf.so
   /opt/intel/fce/10.1.022/lib/libimf.so (the same for cce)

which path seems to be correctly sourced by iccvars.sh and
ifortvars.sh (incidentally, both files are -rw-r--r-- root root;
correct that non executable?)

echo $LD_LIBRARY_PATH
returned, inter alia,
/opt/intel/mkl/10.1.2.024/lib/em64t:/opt/intel/mkl/10.1.2.024/lib/em64t:/opt/intel/cce/10.1.022/lib:/opt/intel/fce/10.1.022/lib
(why twice the mkl?)

I surely miss to understand something fundamental. Hope other eyes see better

A kind person elsewhere suggested me on passing "The use of -rpath
during linking is highly recommended as opposed to setting
LD_LIBRARY_PATH at run time, not the least because it hardcodes the
paths to the "right" library files in the executables themselves"
Should this be relevant to the present issue, where to learn about
-rpath linking?

thanks
francesco pietra