Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] OpenMPI and R
From: Jeffrey Squyres (jsquyres_at_[hidden])
Date: 2012-04-06 08:45:38


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/