When emerging sys-libs/db-1.85-r1 on an alpha system the /usr/bin/db1_dump185 command is linked against a non-existant library of libdb.so.2.1. Reproducible: Always Steps to Reproduce: 1. emerge sys-libs/db-1.85-r1 # on alpha cpu machine 2. ldd /usr/bin/db1_dump185 3. Actual Results: # ldd /usr/bin/db1_dump185 libdb.so.2.1 => not found libc.so.6.1 => /lib/libc.so.6.1 (0x000002000002a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020000000000) or # /usr/bin/db1_dump185 /usr/bin/db1_dump185: error while loading shared libraries: libdb.so.2.1: cannot open shared object file: No such file or directory Expected Results: # ldd /usr/bin/db1_dump185 libdb.so.2.1 => /usr/lib/libdb.so.2.1 libc.so.6.1 => /lib/libc.so.6.1 (0x000002000002a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020000000000) or # /usr/bin/db1_dump185 usage: db_dump185 [-p] [-f file] db_file Portage 2.0.50-r6 (default-alpha-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.26) ================================================================= System uname: 2.4.26 alpha EV56 Gentoo Base System version 1.4.9 distcc 2.13 alpha-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CFLAGS="-O2 -mtune=ev56 -mcpu=ev56 -pipe" CHOST="alpha-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mtune=ev56 -mcpu=ev56 -pipe" DISTDIR="/kits/gentoo/distfiles" FEATURES="ccache" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/kits/gentoo/packages/alpha-ev56" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X alpha berkdb cdr crypt cups encode foomaticdb gdbm gif gpm gtk gtk2 guile imlib jpeg ldap libg++ libwww mikmod motif moznomail moznoxft mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang smooth spell ssl tcltk tcpd truetype xml2 xmms xv zlib"
Sean, do you have any idea why/how this is happening, and how to resolve it?
Created attachment 29818 [details] difference between x86 and alpha build of db-1.85-r1 For some reason libdb.so.2.1 is built on alpha, libdb.so.2 is built on x86. I don't know why yet this happens. Everything in the build goes correctly, but the ebuild has hardcoded libdb.so.2 for installation. The quick fix would be to solve the problem in the ebuild. I would still like to know why the version is different on alpha, though.
I have the same problem on alpha; revdep-rebuild keeps on telling me sys-libs/db-1.85-r1 should be rebuilt after re-emerging the package...
Is this a forgotten one? I still have this problem...
Yes the sys-libs/db-1.85-r1 ebuild tries and create symlinks but doesn't seem to generate the real shared library. I think the db-1.85 configured make files and scripts are not working correct for alpha and probably need to be patched. root # qpkg -nc -l sys-libs/db-1.85-r1 sys-libs/db-1.85-r1 CONTENTS: /usr /usr/bin /usr/bin/db1_dump185 /usr/lib /usr/lib/libndbm.a -> libdb1.a 1094125200 /usr/lib/libdb1.a /usr/share /usr/share/doc /usr/share/doc/db-1.85-r1 /usr/share/doc/db-1.85-r1/ps /usr/share/doc/db-1.85-r1/ps/dbopen.3.ps.gz /usr/share/doc/db-1.85-r1/ps/mpool.3.ps.gz /usr/share/doc/db-1.85-r1/ps/recno.3.ps.gz /usr/share/doc/db-1.85-r1/ps/btree.3.ps.gz /usr/share/doc/db-1.85-r1/ps/libtp.usenix.ps.gz /usr/share/doc/db-1.85-r1/ps/hash.usenix.ps.gz /usr/share/doc/db-1.85-r1/ps/hash.3.ps.gz /usr/share/doc/db-1.85-r1/hash /usr/share/doc/db-1.85-r1/hash/README.gz /usr/share/doc/db-1.85-r1/README.gz /usr/share/doc/db-1.85-r1/changelog.gz /usr/include /usr/include/db1 /usr/include/db1/db.h /usr/include/db1/mpool.h /usr/include/db1/ndbm.h /usr/include/ndbm.h -> db1/ndbm.h 1094125200 /usr/lib/libndbm.so -> libdb1.so.2 1094125200 /usr/lib/libdb.so.2 -> libdb1.so.2 1094125200 /usr/lib/libdb1.so -> libdb1.so.2 1094125200
Something like that yes, and db-1.85-r2 doesn't fix it either...
Created attachment 53627 [details, diff] db.1.85.alpha-fix.patch This issue comes from db.1.85.patch which is applied to the source when unpacking (lines 1165-1170). For an unknown (or since long forgotten) reason, the version of libdb is set to 2 for all archs except alpha where it is set to 2.1. To fix that, you can apply my patch after db.1.85.patch in src_unpack() section in the ebuild. ebuild db-1.85-r2 has the same pbm and can be also treated the same way.
Here is the fix for this problem to match the db.1.85.alpha-fix.patch change that was made. alpha9 ~ # diff -c /var/tmp/db-1.85-r2.ebuild.orig /usr/portage/sys-libs/db/db-1.85-r2.ebuild *** /var/tmp/db-1.85-r2.ebuild.orig Thu Jun 16 07:59:54 2005 --- /usr/portage/sys-libs/db/db-1.85-r2.ebuild Thu Jun 16 07:54:36 2005 *************** *** 33,43 **** src_install() { cd ${S}/PORT/linux newlib.a libdb.a libdb1.a || die "newlib.a failed" ! newlib.so libdb.so.2 libdb1.so.2 || die "newlib.so failed" ! dosym libdb1.so.2 /usr/$(get_libdir)/libdb1.so ! dosym libdb1.so.2 /usr/$(get_libdir)/libdb.so.2 ! dosym libdb1.so.2 /usr/$(get_libdir)/libndbm.so dosym libdb1.a /usr/$(get_libdir)/libndbm.a dodir /usr/include/db1 --- 33,48 ---- src_install() { cd ${S}/PORT/linux + if [ "${ARCH}" = "alpha" ]; then + SOVER=2.1 + else + SOVER=2 + fi newlib.a libdb.a libdb1.a || die "newlib.a failed" ! newlib.so libdb.so.${SOVER} libdb1.so.${SOVER} || die "newlib.so failed" ! dosym libdb1.so.${SOVER} /usr/$(get_libdir)/libdb1.so ! dosym libdb1.so.${SOVER} /usr/$(get_libdir)/libdb.so.${SOVER} ! dosym libdb1.so.${SOVER} /usr/$(get_libdir)/libndbm.so dosym libdb1.a /usr/$(get_libdir)/libndbm.a dodir /usr/include/db1
I confirm that the patch from Comment #8 works... pan db # ldd /usr/bin/db1_dump185 libdb.so.2.1 => /usr/lib/libdb.so.2.1 (0x000002000002e000) libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000054000) /lib/ld-linux.so.2 (0x0000020000000000)
Ok guys, can you please apply the fix in Comment #8 ? Thanks Ferdy
the patch looks like it's obviously correct if you want paul, i'll add it
Go ahead. It seems strange to me that alpha has a different SOVER but the makefile expressly does it this way, so there must be a good reason. At least it's not a bug, so this patch is probably best.
thanks all, try db-1.85-r3 which should work fine
Well, after these 1.5 years this package doesn't seem to be needed on my system anymore, but without trying, I'm convinced it will work fine too... ;-)
we promise bug fixes within 2 years or your money back !
Well, in that case it's fixed too soon ;-)
