> 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. > 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? > Solutions: > > - 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. > > Brian > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users >
