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
