Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-09-05 11:42:11

On Sep 5, 2012, at 11:36 AM, Samuel Thibault wrote:

>> 1. We do not allow "./configure --enable-static --enable-shared". Even though that's valid Automake/Libtool (i.e., it'll generate libhwloc.a *and*, we don't allow it.
> Well, actually for instance Debian builds once with -static, and once
> with -shared, and installs both...

That scenario is fine. It's just the "build both at once" scenario that isn't allowed.

> BTW, I guess it wasn't attempted to make OMPI plugins work on windows?
> The nightmare is even worse there...

I don't know if Shiqing (the main OMPI Windows maintainer) allows plugins on Windows, or if he slurps the plugins into libmpi.dll.

>> 2. If --enable-shared (which is OMPI's default), we build plugins as DSOs and do not link them against (and friends).
>> 3. If --enable-static, we build plugins are part of libmpi.a (and friends). Issues #9 and #12 from table 1 on the wiki are avoided, as are
>> 4. However: in both / libmpi.a cases, we can still allow the use of DSOs -- e.g., if a vendor drops in another DSO plugin that OMPI will just find/load/use at run time. This is cases #2, #5, #8, and #11 in table 1.
> Don't these vendor-provided DSO need to use some OMPI functions?

Yes. And they work fine for #2 (above).

> That said it looks a not too bad solution: avoiding loading plugins in
> the static case, but still allowing third-party plugins, and it's up to
> the user to make it work :)

That's generally the conclusion we came to. The "need to open (hwloc|OMPI) as a plugin itself" case is not common. Specifically, it came up in the case of Python, Perl, and R MPI bindings.

Jeff Squyres
For corporate legal information go to: