lilgoomba
asked on
Shared library not found when running Subversion
We have had Subversion running on a Fedora 10 64 bit system for many years now, and just recently it stopped working with an upgrade. Unfortunately we don't know what the upgrade was that broke it, but we end up getting this:
svn: error while loading shared libraries: libdb-4.3.so: cannot open shared object file: No such file or directory
I've attached the ldd report which seems to show that all of the dependencies are in place. Does anyone have an idea as to why I'm seeing this error?
svn: error while loading shared libraries: libdb-4.3.so: cannot open shared object file: No such file or directory
I've attached the ldd report which seems to show that all of the dependencies are in place. Does anyone have an idea as to why I'm seeing this error?
# ldd svn
linux-vdso.so.1 => (0x00007fffd92f7000)
libsvn_client-1.so.0 => /usr/lib64/libsvn_client-1.so.0 (0x00007fa0d3c13000)
libsvn_wc-1.so.0 => /usr/lib64/libsvn_wc-1.so.0 (0x00007fa0d39cc000)
libsvn_ra-1.so.0 => /usr/lib64/libsvn_ra-1.so.0 (0x00007fa0d37c1000)
libsvn_diff-1.so.0 => /usr/lib64/libsvn_diff-1.so.0 (0x00007fa0d35b6000)
libsvn_ra_local-1.so.0 => /usr/lib64/libsvn_ra_local-1.so.0 (0x00007fa0d33ae000)
libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 (0x00007fa0d3184000)
libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 (0x00007fa0d2f7d000)
libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0 (0x00007fa0d2d57000)
libsvn_fs_base-1.so.0 => /usr/lib64/libsvn_fs_base-1.so.0 (0x00007fa0d2b28000)
libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0 (0x00007fa0d2927000)
libsvn_ra_svn-1.so.0 => /usr/lib64/libsvn_ra_svn-1.so.0 (0x00007fa0d2710000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003ca5000000)
libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0 (0x00007fa0d24ec000)
libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0 (0x00007fa0d22e1000)
libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0 (0x00007fa0d208f000)
libz.so.1 => /lib64/libz.so.1 (0x0000003c96600000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x0000003845000000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00000037aac00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003ca5400000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00000037a6a00000)
libdb-4.7.so => /lib64/libdb-4.7.so (0x0000003ca6400000)
libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00000037aa400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c96200000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003c95e00000)
libneon.so.27 => /usr/lib64/libneon.so.27 (0x00000037ade00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c95600000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003c99200000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003f67200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c95200000)
libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x0000003df2000000)
libpakchois.so.0 => /usr/lib64/libpakchois.so.0 (0x0000003ca3c00000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003f67a00000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003f67e00000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003a9ae00000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003f67600000)
libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x0000003cad800000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x0000003843c00000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x0000003caa400000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003a9b200000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003c9d200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003a99200000)
Try running 'ldconfig -v'
ASKER
I did that, and I get the same thing. It looks like it's compiled against the wrong shared library and it won't switch to the new one. Is there a way to force it to look at the new version of libdb?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
When it comes to Red Hat-like OS (i.e. Fedora, CentOS), it's always best to use RPMs rather than compiling code for mainstream products like Subversion, Apache, etc. RPMs are tracked in bugzilla and other community-based forums, thus gives an added outlet for fixing issues with code.