Well, there are some other rather simple ways to do it too.

1. Follow the FAQs and setup your remote login environment properly


2. add "-x LD_LIBRARY_PATH" to your mpirun cmd line, as explained in this FAQ


If you are using ssh/rsh for your launch, then #2 will resolve the problem as we set the LD_LIBRARY_PATH in ssh prior to actually starting the orted. If you are launching via some other resource manager, then #2 will indeed not solve the problem as there is no way to preset the environment. However, most RMs (including Torque, Slurm, LSF, and SGE) allow passing of the environment if configured to do so - you might check with your sys admin to see if they will do it for you.

On Jun 30, 2013, at 12:52 PM, Alan Wild <alan@madllama.net> wrote:

I'm surprised that there are users still reporting issues getting this to work, but as I'm still seeing notes in the digest I wanted to share (what I believe the issue is) and how I've fixed it.

If you don't take special measures, OpenMPI will be dynamically linked and have runtime dependencies on several of Intel's .so files.  However, passing LD_LIBRARY_PATH has an option on mpirun is often not sufficient because the orted process itself has these dyanmic dependencies... so when you invoke mpirun, it fires up and launches orted on the remote hosts (with the intention of passing LD_LIBRARY_PATH or whatever to the remote process but the remote process immediately fails because it cannot resolve its dependencies (and LD_LIBRARY_PATH is never setup on the far side).

So I see two options:

1) linking orted statically.  (Not sure if I've ever done this)

2) Passing an rpath in your openmpi link options so that oreted can resolve its own dependencies without needing an LD_LIBRARY_PATH

You can do #2 by using something similar to the following on your configure line

./configure --prefix=/path/to/where/to/install/openmpi LDFLAGS="-Wl,--enable-new-dtags -Wl,-rpath,/path/to/intel/compiler/lib_directory"

users mailing list