On Apr 5, 2012, at 9:07 PM, Benedict Holland wrote:
> Oh how interesting and I hope this helps someone. Following another link, I had to use:
>
> ./configure --prefix /usr --enable-shared --enable-static
This makes sense. You were falling victim to the fact that R dlopens libmpi as a dynamic library in a private namespace. Hence, when Open MPI then dlopens its own plugins, it can't find libmpi's symbols. This is a generic problem with any system that opens plugins that, themselves, open plugns. I wish there was a better solution to this -- the OS guys need to give us a better mechanism here. :-(
OMPI's --enable-static option does two things:
- it builds libmpi.a (vs. libmpi.so)
- it slurps all of OMPI's plugins into libmpi.a (so it doesn't need to dlopen anything at run-time)
It's the latter point that is saving you.
Note that you could also just --disable-dlopen (vs. --disable-shared --enable-static), which just does the latter of the above things (meaning: OMPI still builds libmpi.so), and it should also work for you.
> when compiling this for Rmpi. Just curious, why isn't --enable-static a default option?
Among other reasons, shared libraries generally help save memory at run time. This is somewhat important as core counts go up. If you "mpirun -np 32" on a single, 32-core machine, would you rather have 32 independent copies of libmpi.a loaded into RAM, or just one copy that all processes share?
Using libmpi.so enables the latter option.
Make sense?
--
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}