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)" <jsquyres_at_[hidden]> wrote:
> On Apr 14, 2014, at 10:59 AM, Mike Dubman <miked_at_[hidden]> 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
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> devel mailing list
> 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
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/