Hide Forgot
Description of the problem: There is a missing symbolic link that causes failures in the execution of several HPC applications that require the library libibverbs.so when using the RDMA included with RHEL 6.1. This occurs because there is missing a symbolic link from /usr/lib64/libibverbs.so.1 to /usr/lib64/libibverbs.so in order to have the correct hierarchy. Version-Release number of selected component (if applicable): libibverbs-1.1.4-2.el6.x86_64 How reproducible is: Always happens Steps to Reproduce: 1. Perform the installation of RHEL 6.1 with Infiniband support. 2. Execute the ldconfig -p | grep libibvers.so command and check the symbolic link is missing, for this reason HPC applications look for it and fails. Actual results: No symbolic link located at /usr/lib64/libibverbs.so Expected Results: Have the symbolic link /usr/lib64/libibverbs.so pointing to /usr/lib64/libibverbs.so.1 Additional Info: This problem does not happen with OFED packages from OFA.
This is not a bug. This happens because you did not install the libibverbs-devel package and that is the one that provides the link from libibverbs.so to libibverbs.so.1. No application should *EVER* be linking against libibverbs.so unless it is a compile time link, not a runtime link. If your application is trying to runtime link against libibverbs.so instead of libibverbs.so.1, then your application's build environment is seriously broken and should be fixed immediately. Runtime linking against a shared library without at *least* the major number of the library included completely negates the ability to maintain backward compatibility libraries while also installing new libraries with a new version that are not ABI compatible with the old ones. So here's the way compat library versioning works and why the .so symlink is in the -devel package: For any given library, standard practice is that <library>.so.X.Y will maintain ABI across updates to Y, but not across updates to X. So going from libibverbs.so.1 to libibverbs.so.2 it is expected that any application must be recompiled to use libibverbs.so.2. Going from libibverbs.so.1.1.5 to libibverbs.so.1.2.0 would typically maintain a back compatibility wrapper in the library itself via the use of library symbol versions such that an application compiled against libibverbs.so.1.1.5 will continue to work with libibverbs.so.1.2.0. During program compile time, we ignore all versions on the library and instead just link against the libibverbs.so. This is because it is assumed (or called out somewhere in some spec, maybe POSIX or somewhere else) that the unversioned libibverbs.so will match the installed devel files in /usr/include. No version information is needed at compile time this way, and we will always select the right actual library because the -devel package that provides the build headers will also provide the link to the right library. However, part of the normal build procedures, if you use gcc as your linker and specify -libverbs as a library on the link command, is that all the proper versions will get filled in as part of the binary output and when you later run the program, ld.so knows specifically which library to link against by the major number. Now, usually the only time I have someone come to me and say that we are missing the .so link and OFED has it is when they are bypassing the gcc linker and doing runtime dynamic library linkage themselves. That's when they hit this problem. And that's when I have to explain that you can't do that. It breaks upgrades and leaves your program susceptible to unexplained and random crashes should we update libibverbs to a new major version. You have to include at least the major number of the library if you are going to dynamically link against this stuff yourself.