Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] trying to use personal copy of 1.7.4
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2014-04-24 14:07:12

On Mar 13, 2014, at 3:15 PM, Ross Boylan <ross_at_[hidden]> wrote:

> The motivation was
> notes
> ----------------------------------
> 2007-10-24, version 0.5-5:
> dlopen has been used to load explicitly. This is mainly useful
> for Rmpi under OpenMPI where one might see many error messages:
> mca: base: component_find: unable to open osc pt2pt: file not found
> (ignored)
> if is not loaded with RTLD_GLOBAL flag.
> -------------------------------------
> I think I'll try changing to to try first so that it picks up
> if available. I've already rebuilt R, though it looks as if
> Rmpi may have been the source of the problems.

If you care for the reason why, it's because many (most? all?) of OMPI's plugins depend on symbols in the main MPI library.

Hence, if those symbols can't be found in the process' namespace when OMPI tries to dlopen one of its plugins, that dlopen will fail due to the symbols it needs not being able to be resolved.

It seems weird because *is* in the process (obviously), but it just can't be found by the plugin because may well be in a private namespace -- and therefore its symbols are hidden from the plugin that is being dlopened. Weird, but true.

I honestly don't know what happens if you have a library opened in a private namespace in a process and then you dlopen it again in a public namespace in the same process. Do you actually get a second copy of libmpi (with a second copy of all of its global symbols), or is the linker smart enough to realize you already have it loaded and effectively move it into the public namespace?

I'm not sure.

Jeff Squyres
For corporate legal information go to: