Open MPI logo

Open MPI User's Mailing List Archives

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

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-03-22 07:55:30


On Mar 15, 2007, at 12:18 PM, Michael wrote:

> I'm having trouble with the portability of executables compiled with
> OpenMPI. I suspect the sysadms on the HPC system I'm using changed
> something because I think it worked previously.
>
> Situation: I'm compiling my code locally on a machine with just
> ethernet interfaces and OpenMPI 1.1.2 that I built.
>
> When I attempt to run that executable on a HPC machine with OpenMPI
> 1.1.2 and InfiniBand interfaces I get messages about "can't find
> libmosal.so.0.0" -- I'm certain this wasn't happening earlier.
>
> I can compile on this machine and run on it, even though there is no
> libmosal.* in my path.
>
> mpif90 --showme on this system gives me:
>
> /opt/compiler/intel/compiler91/x86_64/bin/ifort -I/opt/mpi/x86_64/
> intel/9.1/openmpi-1.1.4/include -pthread -I/opt/mpi/x86_64/intel/9.1/
> openmpi-1.1.4/lib -L/opt/mpi/x86_64/intel/9.1/openmpi-1.1.4/lib -L/
> opt/gm/lib64 -lmpi_f90 -lmpi -lorte -lopal -lgm -lvapi -lmosal -lrt -
> lnuma -ldl -Wl,--export-dynamic -lnsl -lutil -ldl

Based on this output, I assume you have configured OMPI with either --
enable-static or otherwise including all plugins in libmpi.so, right?

> I suspect that read access to libmosal.so has been removed and
> somehow when I link on this machine I'm getting a static library,
> i.e. libmosal.a
>
> Does this make any sense?

This would be consistent with what you described above -- that
libmosal.so (a VAPI support library) is available on the initial
machine, so your MPI executable will have a runtime dependency on
it. But then on the second machine, libmosal.so is not available, so
the runtime dependency fails. But if you compile manually,
libmosal.a is available and therefore the application can be created
with compile/link-time resolution (vs. runtime resolution).

> Is there a flag in this compile line that permits linking an
> executable even when the person doing the linking does not have
> access to all the libraries, i.e. export-dynamic?

No. All the same Linux/POSIX linking rules apply for creating an
executable; we're not doing anything funny in this area.

FYI: --export-dynamic tells the linker that symbols in the libraries
should be available to plugins that are opened later. It's probably
not relevant for the case where you're not opening any plugins at
runtime, but we don't differentiate between this case because the
decision whether to open plugins or not is a runtime decision, not a
compile/link-time decision.

-- 
Jeff Squyres
Cisco Systems