On Apr 14, 2014, at 3:27 PM, Mike Dubman <miked_at_[hidden]> wrote:
> 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.
â¯â¯â¯ ls -l /usr/lib/libibverbs*
lrwxrwxrwx 1 root root 19 Dec 16 06:59 /usr/lib/libibverbs.so -> libibverbs.so.1.0.0*
lrwxrwxrwx 1 root root 19 Dec 16 06:59 /usr/lib/libibverbs.so.1 -> libibverbs.so.1.0.0*
-rwxr-xr-x 1 root root 52060 Dec 3 11:43 /usr/lib/libibverbs.so.1.0.0*
As you can see, my libibverbs has shared library version 1.0.0, not 0.0.0.
> The libibverbs can have experimental verbs included but libibverbs version still will be indicating the libtool version is "0:0:0".
That's bad software release methodology. You should fix *that*.
Shared libraries have version numbers for a reason. They should be used properly.
> 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.
Sure -- registering an MCA param like I described does all of these things without needing any new infrastructure in OMPI. You could put such version numbers in today.
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/