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* libhwloc.so), 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 libmpi.so (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.so / 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
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}