this was true if all external libraries were maintaining ABI compatibility indicator properly with libtool. Let`s check your favorite, libibverbs :), the version is always 0.0.0 in libibverbs.so.0.0.0 so openib btl will not fail on link. The libibverbs can have experimental verbs included but libibverbs version still will be indicating the libtool version is "0:0:0".
So, the only way for sysadmin/user to know if he has a right version of libibvers installed is to check verbs.getVersion() and see if it is matches to one which includes experimental verbs and then he will know that there is a problem. but for us, the most powerful case is the one that you described: compare ompi_info output on head and compute node and warn user if differ. Also, to provide an infrastructure to digitize release notes. On Mon, Apr 14, 2014 at 9:52 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote: > BTW, I should point out that this really is only relevant if libfoo A.B.C > and X.Y.Z are *ABI compatible*, but not *behavior compatible*. > > If A.B.C and X.Y.Z are not ABI compatible, then ompi_info will fail just > like the MPI processes fail (i.e., it may not be able to dlopen the > component using libfoo X.Y.Z). > > A useful case to determine behavior compatibility is if libfoo exports a > capability vector; A.B.C supports capability 13 and 27, but X.Y.Z supports > only 13. If the OMPI component is smart enough to detect these run-time > behavior differences, it'll only use capability 13 with X.Y.Z but will use > both 13 and 27 with A.B.C. > > > > > On Apr 14, 2014, at 2:48 PM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> > wrote: > > > On Apr 14, 2014, at 10:59 AM, Mike Dubman <mi...@dev.mellanox.co.il> > wrote: > > > >> There is no correlation between built_with and running_with versions of > external libraries supported by OMPI. > > > > Ah, I see -- yes, that's the disconnect here. > > > > I think one use case that shows this is the following: > > > > 1. Admin Bob builds Open MPI on the cluster head node with dependent > library libfoo.so version A.B.C, which is a fully supported configuration. > Therefore, the appropriate configure.m4's are happy, and everything builds > and installs. > > > > 2. But when User Betty goes to run, the libfoo.so on the back-end > compute nodes is accidentally version X.Y.Z, which is *not* supported. And > Bad Things happen. > > > > 3. So you'd like to be able to run ompi_info on the head node and on the > compute nodes and compare the output, and see an obvious difference of > A.B.C vs. X.Y.Z in the dependent library of a given component, and use that > to help figure out what is going wrong. > > > >> The next release of external library does not mean we should remove > code in ompi for all previous supported releases for the same library. > > > > This is another use case: OMPI was built against dep library libfoo.so > A.B.C (which is a supported config). But then someone does an upgrade of > libfoo *without rebuilding OMPI*, and now OMPI run-time links against > libfoo.so X.Y.Z, which is no longer a supported configuration. > > > >> Why are you so against it? I don`t see any issue with printing ext lib > version number in the MCA description, something that can improve > sysadmin/user-experience. > > > > FWIW, we've done this before by putting them in read-only MCA parameters > -- we've called them "info" MCA params. > > > > I don't see any in the code base today, but I know we've definitely had > version kinds of MCA params before. > > > > -- > > 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/2014/04/14513.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/2014/04/14514.php >
