Open MPI logo

Open MPI User's Mailing List Archives

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

Subject: Re: [OMPI users] dlopening openmpi libs (was: Re: Problems in 1.3 loading shared libs when usingVampirServer)
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-03-25 12:34:03


Just to strengthen what Brian said...

We agree that what you cite is a problem. The only issue is that we
don't know of any way to do it better -- Brian laid out the 3 possible
options below pretty well. --enable-mca-static might be a decent
solution for you; you still build libmpi.so (not libmpi.a), but all
the plugins are slurped up into libmpi instead of being dlopened at
run-time.

It's really a larger issue than just Open MPI -- private namespaces
are, in general, a Good Thing, but they are problematic for *any*
plugin-based system that gets opened in a private namespace. What
would be a Real solution would be somehow having a way that Open MPI
could dlopen its plugins *within* its private namespace. That's
unfortunately beyond our control to influence.

On Mar 25, 2009, at 9:10 AM, Brian W. Barrett wrote:

> On Mon, 23 Mar 2009, Olaf Lenz wrote:
>
> > and the solution that is described there still looks as though it
> should
> > still work now, or shouldn't it? Just link all the OpenMPI plugins
> against
> > the base OpenMPI libraries, and it should work. Or am I wrong?
>
> I believe your suggestion will not work, certainly not portably. In
> fact,
> it will die in horrible ways. We used to link in the way you
> suggested,
> and what you end up with is a bunch of copies of libmpi, all in
> their own
> namespace. Hardly helpful :).
>
> Unfortunately, there are only three rational solutions I've thought
> of to
> the problem:
>
> * Do nothing, my prefered solution
> * Stop building components by default
> * Have libmpi be a thin wrapper, which dlopens Open MPI's guts into
> the
> public namespace, and the guts then dlopen all the components.
>
> Obviously, the first serves the greatest community and involves the
> least
> amount of work. However, packagers such as the Linux distributions
> should
> make a decision about how to best package Open MPI -- perhaps shipping
> it built with components is not the ideal solution for their
> infrastructure.
>
> I did want to point out one incorrect statement in your e-mail. While
> specifying "--enable-shared --enable-static" to configure will cause
> components to be linked into libmpi rather than built as stand-alone
> entities, a better way to accomplish that is "--enable-mca-static",
> which
> will build all the components into libmpi.so, but not also cause
> libmpi.a
> to be built.
>
> Brian
> _______________________________________________
> users mailing list
> users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/users

-- 
Jeff Squyres
Cisco Systems