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 jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
