On Sep 5, 2012, at 11:12 AM, Brice Goglin wrote: >> To be clear: we have exactly the same situation in OMPI, and we do not link >> any of our DSOs against libmpi.so (we used to, but we don't any more because >> of the discussion on the https://svn.open-mpi.org/trac/ompi/wiki/Linkers >> wiki page). > > So I would need to remove -no-undefined from plugins ldflags and darwin > (and you?) may be happy again? But iirc, removing this flag broke > something else, I'll check again.
Ah, yes; I confess that I have not looked closely on the components branch. :-( But yes; you should not have --no-undefined when building the plugins. It's fine for building libhwloc, I think. > By the way, we have almost no internal state in hwloc. Fair enough. So let's get back to your question: how to fix this? In OMPI, we settled on the compromise that I (briefly) mentioned earlier. Here it is spelled out more specifically: 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. 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. 5. All that being said, if it is desirable to open libmpi in a private linker scope, we define that that will only work if you slurp all the plugins into libmpi (either libmpi.so, in which case it can directly be dlopened, or in libmpi.a, in which case libmpi.a must be linked into something_else.so which is dlopened). And the dlopen functionality in libmpi just plain won't work -- e.g., vendors can't drop in new DSOs to an OMPI installation and expect them to work (because any DSOs that libmpi opens won't be able to find libmpi's symbols in the process space, because libmpi itself is in a private scope). Clear as mud? :-) -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
