I guess I didn’t make it clear in my prior comment, so let me try again. I understand about dlopen and the fix that George proposed - we had internally discussed this as well. However, the questions that raises are:
1. how does the distro (Michal) decide which PSM module to disable by default in their package? 2. how does the user “discover” that their fabric has automatically been disabled, especially since this has never been the case before? I’ll raise the procedural question at our next telecon. I certainly take no pleasure out of generating releases, so if we have a better solution, I’m all for it! > On Sep 3, 2015, at 5:55 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > > I agree with what George says. > > AFAIK, Red Hat builds Open MPI support for dlopen, so the config file option > is probably suitable. > > However, I have to admit that I resent the fact that PSM's poor upgrade path > design is forcing both the Open MPI and libfabric communities to have similar > confusing conversations (e.g., see > https://github.com/ofiwg/libfabric/issues/1258#issuecomment-137426271). > > Specifically: because of the design of PSM1/PSM2, both Open MPI and libfabric > will have to adjust their configury and use dlopen/function pointer > indirection to "solve" the problem of supporting both PSM1 and PSM2. > > Does that seem weird to anyone else? > > IMNSHO, if you have to have extremely confusing conversations in multiple > software communities explaining your configury, function-pointer-indirection > code (i.e., PR https://github.com/ofiwg/libfabric/pull/1259), compilation, > and linking scheme to upgrade to a new library, you're doing it wrong. > > > > >> On Sep 3, 2015, at 7:19 AM, George Bosilca <bosi...@icl.utk.edu> wrote: >> >> Hi Michael, >> >> I might have missed some context when proposing this solution. As Gilles >> suggested if you build Open MPI without support for dlopen (configure option >> --disable-dlopen) this simple solution will not work because the symbol >> conflict issue is generated deep inside the constructors of the 2 libraries. >> >> Yes, the "mtl = ^psm" (or ^psm2 depending on which one you want to disable) >> should go in the openmpi-mca-params.conf that gets installed in the >> $(sysconfigdir). >> >> Thanks, >> George. >> >> >> On Thu, Sep 3, 2015 at 5:14 AM, Michal Schmidt <mschm...@redhat.com> wrote: >> [I apologize for not threading the email properly. I was not subscribed >> before and found the conversation in the web archive.] >> >> Hello, >> >> I am the one who discovered the PSM vs. PSM2 library conflict and >> proposed the temporary workaround of having two builds of the openmpi >> package. >> >> George Bosilca wrote: >>> 3. Except if the distro builds OMPI statically, I see no reason to >>> have 2 build of OMPI due to conflicting symbols between two shared >>> libraries that OMPI MCA load willingly. Why a simple "mtl = ^psm" in >>> the OMPI system wide configuration file is not enough to solve the >>> issue? >> >> Thank you for this suggestion. It would go into openmpi-mca-params.conf, >> right? I will try it. >> >> Regards, >> Michal >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/09/17927.php >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/09/17928.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/09/17931.php
