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
