George, I think you misunderstand the difference between the two modules. PSM supports one type of fabric, and PSM2 supports a different one. They are not interchangeable.
I agree with your second point. If you have a way of resolving it, I would welcome hearing it. So far, the problems have been a lack of testing that fails to identify problems, frequently due to missed use-cases. Perhaps someone has a better suite of tests (or would volunteer to help develop them), and/or would offer up access to a broader range of environments? As for why the distro would provide two rpm’s: you can argue that with them. :-) However, I believe the issue is the same one we have with hcoll/ml and libnl/libnl3 conflicts - and I have yet to see someone propose a reliable fix for either of those. If you can create one, please chime in on the libnl/libnl3 ticket as Gilles and Jeff have spent a lot of time and pain on it. > On Sep 2, 2015, at 9:38 PM, Gilles Gouaillardet <gil...@rist.or.jp> wrote: > > George, > > about your third point : > some libraries does stuff in the constructors, so "mtl = ^psm" might also not > work if OMPI was configure'd with --disable-dlopen. > as far as i know, --disable-dlopen is quite popular (and --disable-shared > --enable-static is not so much) > > Cheers, > > Gilles > > On 9/3/2015 1:31 PM, George Bosilca wrote: >> I might have missed something here but: >> >> 1. I bet that, and I'm certainly using a lower bound here, 99.9% of our >> users will not even notice the issue between PSM and PSM2. >> >> 2. If there is anything that might negatively impact us as a community is >> the recurrent screwed-up with our own releases. For a production-quality >> software, releasing a new "stable" version every 3 weeks is not being >> reactive, is being obnoxious. >> >> 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? >> >> George. >> >> >> On Wed, Sep 2, 2015 at 11:47 PM, Ralph Castain <r...@open-mpi.org >> <mailto:r...@open-mpi.org>> wrote: >> I’m afraid that won’t solve the problem - the distro will still feel the >> need to release -two- versions of OMPI, one with PSM and one with PSM2. >> Ordinarily, I wouldn’t care - but this creates user confusion and reflects >> on us as a community. >> >> >> > On Sep 2, 2015, at 6:50 PM, Gilles Gouaillardet <gil...@rist.or.jp >> > <mailto:gil...@rist.or.jp>> wrote: >> > >> > Ralph, >> > >> > what about automatically *not* building PSM2 if PSM is built and PSM2 is >> > not explicitly required ? >> > /* in order to be future proof, we could even do that only if we detect a >> > symbol conflict */ >> > we could abort if ompi is configure'd with both --with-psm and >> > --with-psm2, or simply do nothing >> > (the end user might know what he/she is doing, and there will be nothing >> > to do on the ompi side >> > when this gets fixed by the PSM folks) >> > >> > Cheers, >> > >> > Gilles >> > >> > On 9/3/2015 10:21 AM, Ralph Castain wrote: >> >> Hi folks >> >> >> >> I regret to say that 1.10.0 is hitting an issue with at least one >> >> upstream distro. Apparently, there is a symbol conflict between the PSM >> >> and PSM2 libraries that precludes building both of those MTLs at the same >> >> time. This is leading the distro to push for release of two OMPI 1.10.0 >> >> builds - one with PSM and the other with PSM2. >> >> >> >> IMO, this is a very undesirable situation. I agree with the distro that >> >> delaying release for some significant time as this would impact everyone >> >> else’s users. Therefore, assuming that the PSM team is unable to quickly >> >> resolve the problem in their libraries, my inclination is to release an >> >> immediate 1.10.1 with the PSM2 MTL removed. >> >> >> >> I’m soliciting input - any opinions? >> >> Ralph >> >> >> >> _______________________________________________ >> >> devel mailing list >> >> de...@open-mpi.org <mailto:de...@open-mpi.org> >> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> >> Link to this post: >> >> http://www.open-mpi.org/community/lists/devel/2015/09/17919.php >> >> <http://www.open-mpi.org/community/lists/devel/2015/09/17919.php> >> > >> > _______________________________________________ >> > devel mailing list >> > de...@open-mpi.org <mailto:de...@open-mpi.org> >> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> > Link to this post: >> > http://www.open-mpi.org/community/lists/devel/2015/09/17920.php >> > <http://www.open-mpi.org/community/lists/devel/2015/09/17920.php> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org <mailto:de...@open-mpi.org> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/09/17921.php >> <http://www.open-mpi.org/community/lists/devel/2015/09/17921.php> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org <mailto:de...@open-mpi.org> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/09/17923.php >> <http://www.open-mpi.org/community/lists/devel/2015/09/17923.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/17924.php
