Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI users] shared libraries issue compiling 1.3.1/intel 10.1.022
From: Gus Correa (gus_at_[hidden])
Date: 2009-04-09 15:29:31

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 observations reported
> for gentoo,
> I made a deb package of 10.1.022, icc and ifort.
> ./configure CC icc, CXX icp,

The Intel C++ compiler is called icpc, not icp.
Is this a typo on your message, or on the actual configure options?

F77 and FC ifort --with-libnuma=/usr (not
> /usr/lib so that the numa.h issue is not raised), "make clean",

If you really did "make clean" you may have removed useful things.
What did you do, "make" or "make clean"?

> "mak install" gave no error signals. However, the compilation tests in
> the examples did not pass and I really don't understand why.

Which compilation tests you are talking about?
 From Amber or from the OpenMPI example programs (connectivity_c and
hello_c), or both?

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

To get the right Intel environment,
you need to put these commands inside your login files
(.bashrc or .cshrc), to setup the Intel environment variables correctly:

source /path/to/your/intel/cce/bin/
source /path/to/your/intel/cce/bin/

and perhaps a similar one for mkl.
(I don't use MKL, I don't know much about it).

If your home directory is NFS mounted to all the computers you
use to run parallel programs,
then the same .bashrc/.csrhc will work on all computers.
However, if you have a separate home directory on each computer,
then you need to do this on each of them.
I.e., you have to include the "source" commands above
in the .bashrc/.cshrc files on your home directory in EACH computer.

Also I presume you use bash/sh not tcsh/csh, right?
Otherwise you need to source iccvars.csh instead of

> # dpkg --search
> /opt/intel/fce/10.1.022/lib/ (the same for cce)
> which path seems to be correctly sourced by and
> (incidentally, both files are -rw-r--r-- root root;
> correct that non executable?)

The permissions here are not a problem.
You are supposed to *source* the files, not to execute them.
If you execute them instead of sourcing the files,
your Intel environment will *NOT* be setup.

BTW, the easy way to check your environment is to type "env" on the
shell command prompt.

> returned, inter alia,
> /opt/intel/mkl/
> (why twice the mkl?)

Hard to tell in which computer you were when you did this,
and hence what it should affect.

You man have sourced twice the mkl shell that sets up the MKL
environment variables, which would write its library path more than

When the environment variables get this much confused,
with duplicate paths and so on, you may want to logout
and login again, to start fresh.

Do you need MKL for Amber?
If you don't use it, keep things simple, and don't bother about it.

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

Jody helped you run the hello_c program successfully.
Try to repeat carefully the same steps.
You should get the same result,
the OpenMPI test programs should run.

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

If you are talking about Amber,
you would have to tweak the Makefiles to tweak the linker -rpath.
And we don't know much about Amber's Makefiles,
so this may be a very tricky approach.

If you are talking about the OpenMPI test programs,
I think it is just a matter of setting the Intel environment variables
right, sourcing the properly,
to get the right runtime LD_LIBRARY_PATH.

> thanks
> francesco pietra
> _______________________________________________
> users mailing list
> users_at_[hidden]

I hope this helps.
Gus Correa

Gustavo Correa
Lamont-Doherty Earth Observatory - Columbia University
Palisades, NY, 10964-8000 - USA