> My guess is that Rmpi is dynamically loading libmpi.so, but not
> specifying the RTLD_GLOBAL flag. This means that libmpi.so is not
> available to the components the way it should be, and all goes
> downhill from there. It only mostly works because we do something
> silly with how we link most of our components, and Linux is just
> smart enough to cover our rears (thankfully).
In mpi4py, libmpi.so is linked in at compile time, not loaded using
dlopen. Granted, the resulting mpi4py binary is loaded into python
> The pt2pt component (rightly) does not have a -lmpi in its link
> line. The other components that use symbols in libmpi.so (wrongly)
> do have a -lmpi in their link line. This can cause some problems on
> some platforms (Linux tends to do dynamic linking / dynamic loading
> better than most). That's why only the pt2pt component fails.
Did this change from 1.2.3 to 1.2.4?
> - Someone could make the pt2pt osc component link in libmpi.so
> like the rest of the components and hope that no one ever
> tries this on a non-friendly platform.
Shouldn't the openmpi build system be able to figure this stuff out on
a per platform basis?
> - Debian (and all Rmpi users) could configure Open MPI with the
> --disable-dlopen flag and ignore the problem.
Are there disadvantages to this approach?
> - Someone could fix Rmpi to dlopen libmpi.so with the RTLD_GLOBAL
> flag and fix the problem properly.
Again, my main problem with this solution is that it means I must both
link to libmpi at compile time and load it dynamically using dlopen.
This doesn't seem right. Also, it makes it impossible on OS X to
avoid setting LD_LIBRARY_PATH (OS X doesn't have rpath). Being able
to use openmpi without setting LD_LIBRARY_PATH is important.
> I think it's clear I'm in favor of Option 3.
> users mailing list