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/
