On Apr 14, 2014, at 3:27 PM, Mike Dubman <mi...@dev.mellanox.co.il> 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. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
