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 jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
