On 12 October 2007 at 13:55, Brian Granger wrote:
| > 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
| using dlopen.
AFAIK that is the same for all dynamically loaded extensions for all 'host
systems' I've used (ie Perl, Python, Octave, R, ...), and of course also Rmpi
But I looked some more at mpi4py and the mpipython front-ends for Python. As
I recall, it mentions explicitly that argc/argv need to go to MPI_INIT before
Python does its thing with them. So other caveats may apply -- you may have
to tweak the engine proper. For us, GNU R is unaltered and the suggested
change is local the the Rmpi extension package.
| > - 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
IIRC this is about the RTLD_GLOBAL flag. The default load doesn't use it,
not all symbols are exported and we get the warning. The code still works,
Using the explicit dlopen with the correct flag, the (spurious) warning
disappears. That's what we wanted.
| avoid setting LD_LIBRARY_PATH (OS X doesn't have rpath). Being able
| to use openmpi without setting LD_LIBRARY_PATH is important.
We do net set LD_LIBRARY_PATH. The libmpi.so library still sits where it
always has, in /usr/lib, where ld.so looks anyway. So this doesn't apply.
Three out of two people have difficulties with fractions.