Link to home
Start Free TrialLog in
Avatar of lilgoomba
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?
# 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)

Open in new window

Avatar of Michael Worsham
Michael Worsham
Flag of United States of America image

Try running 'ldconfig -v'
Avatar of lilgoomba
lilgoomba

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
Avatar of lilgoomba
lilgoomba

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.