Emerging sys-libs/gdbm-1.8.3 results in 0 bytes libgdbm.so.2.0.0. This breaks anything previously linked against libgdbm.so.2.0.0. "xemacs: error while loading shared libraries: /usr/lib/libgdbm.so.2: file too short" Symlinking (ln -sf libgdbm.so.3.0.0 libgdbm.so.2.0.0) appears, superficially, to fix this. Reproducible: Always Steps to Reproduce: 1. 2. 3.
It also breaks dev-lang/wml and probably a lot of other packages...
It actually helps to reemerge dev-lang/wml in my case, so it uses the new shared lib, but I don't know if thats the case for all app dyn. linking against libgdbm. If it is the case then using revdep-rebuild from app-portage/gentoolkit should do the trick. Jonathan,should you try to remerge xemacs and see if that helps?
Hi! Same problem here, but re-emerging xemacs did not work: emerge xemacs [...] checking for machine/soundcard.h... no checking for sys/soundcard.h... yes checking for audio/audiolib.h... no checking for TTY-related features checking for ncurses/curses.h... no checking for ncurses/term.h... no checking for ncurses/curses.h... no checking for database support checking for ndbm.h... yes checking for dbm_open in -lgdbm... no Error: Required GNU DBM support cannot be provided. !!! ERROR: app-editors/xemacs-21.4.15 failed. !!! Function src_compile, Line 161, Exitcode 1 !!! (no error message) "revdep-rebuild" did not work: No errors. Re-emerging "gdbm" did not work: No errors, but: emerge --oneshot gdbm [...] --- !empty dir /usr --- !targe sym /usr/lib/libgdbm_compat.so.3 --- !targe sym /usr/lib/libgdbm_compat.so --- !targe sym /usr/lib/libgdbm.so.3 --- !targe sym /usr/lib/libgdbm.so.2 --- !targe sym /usr/lib/libgdbm.so >>> original instance of package unmerged safely. * Please run revdep-rebuild --soname libgdbm.so.2 * Packages compiled against the previous version will not work >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> sys-libs/gdbm-1.8.3 merged. [...] Ok, so I did: "revdep-rebuild --soname libgdbm.so.2". Result: There are no dynamic links to libgdbm.so.2... All done. But xemacs won't start :-( Regards, Florian Evers
I've experienced the same problem - oddly enough only on 1 of 2 machines... One machine builds only libgdbm.so.3.0.0, and removes 2.0.0, the other creates the mentioned libgdbm.so.2.0.0 with a size of zero. emerge info of the machine that creates the 2.0.0 : Portage 2.0.50-r9 (x86, gcc-3.3.4, glibc-2.3.3.20040420-r0, 2.6.7-hardened-r3) ================================================================= System uname: 2.6.7-hardened-r3 i686 AMD Duron(tm) Gentoo Base System version 1.5.1 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon -mcpu=athlon -mmmx -m3dnow -O2 -pipe -fomit-frame-pointer -ffast-math -fforce-addr -falign-functions=4" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon -mcpu=athlon -mmmx -m3dnow -O2 -pipe -fomit-frame-pointer -ffast-math -fforce-addr -falign-functions=4" DISTDIR="/storage/portage/distfiles" FEATURES="autoaddcvs ccache sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ ftp://gentoo.inode.at/source/ http://gentoo.inode.at" MAKEOPTS="-j2" PKGDIR="/storage/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://localhost/gentoo-portage" USE="3dnow acpi apache2 apm berkdb chroot crypt curl erandom exiscan-acl gd gdbm gif gmp gpm hardened hardenedphp imagemagick imap innodb java jpeg ldap libwww maildir mmx mysql nagios-dns nagios-ntp nagios-ping nagios-ssh ncurses nls nptl pam parse-clocks pcre pdflib perl pic pie png python readline samba sasl slang snmp socks5 sse ssl tcpd tetex threads tiff truetype usb vhosts wildlsearch x86 xml xml2 zlib"
Hi, I found a solution that works here. Do: emerge -C gdbm and re-emerge it emerge --oneshot gdbm After that, do a revdep-rebuild --soname libgdbm.so.2 It re-emerged: phyton perl xemacs openoffice ----- Look at this: root@powerstation /home/florian # emerge -C gdbm sys-libs/gdbm selected: 1.8.3 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging sys-libs/gdbm-1.8.3... No package files given... Grabbing a set. <<< obj /usr/share/man/man3/gdbm.3.gz <<< obj /usr/share/info/gdbm.info.gz <<< obj /usr/share/doc/gdbm-1.8.3/README.gz <<< obj /usr/share/doc/gdbm-1.8.3/NEWS.gz <<< obj /usr/share/doc/gdbm-1.8.3/ChangeLog.gz <<< obj /usr/lib/libgdbm_compat.so.3.0.0 <<< obj /usr/lib/libgdbm_compat.la <<< obj /usr/lib/libgdbm_compat.a <<< obj /usr/lib/libgdbm.so.3.0.0 <<< obj /usr/lib/libgdbm.so.2.0.0 <<< obj /usr/lib/libgdbm.la <<< obj /usr/lib/libgdbm.a <<< obj /usr/include/gdbm/ndbm.h <<< obj /usr/include/gdbm/dbm.h <<< obj /usr/include/gdbm.h <<< sym /usr/lib/libgdbm_compat.so.3 <<< sym /usr/lib/libgdbm_compat.so <<< sym /usr/lib/libgdbm.so.3 <<< sym /usr/lib/libgdbm.so.2 <<< sym /usr/lib/libgdbm.so <<< dir /usr/share/doc/gdbm-1.8.3 <<< dir /usr/include/gdbm --- !empty dir /usr/share/man/man3 --- !empty dir /usr/share/man --- !empty dir /usr/share/info --- !empty dir /usr/share/doc --- !empty dir /usr/share --- !empty dir /usr/lib --- !empty dir /usr/include --- !empty dir /usr >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... * Regenerating GNU info directory index... * Processed 205 info files: 1 errors; run with emerge --verbose to view errors. ---- All these libgdbm.so.2.* are gone after re-emerging gdbm: florian@powerstation /usr/lib $ ls -al libgdb* -rw-r--r-- 1 root root 32446 25. Jul 20:51 libgdbm.a -rw-r--r-- 1 root root 15958 25. Jul 20:51 libgdbm_compat.a -rwxr-xr-x 1 root root 748 25. Jul 20:51 libgdbm_compat.la lrwxrwxrwx 1 root root 23 25. Jul 20:51 libgdbm_compat.so -> libgdbm_compat.so.3.0.0 lrwxrwxrwx 1 root root 23 25. Jul 20:51 libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0 -rwxr-xr-x 1 root root 7880 25. Jul 20:51 libgdbm_compat.so.3.0.0 -rwxr-xr-x 1 root root 699 25. Jul 20:51 libgdbm.la lrwxrwxrwx 1 root root 16 25. Jul 20:51 libgdbm.so -> libgdbm.so.3.0.0 lrwxrwxrwx 1 root root 16 25. Jul 20:51 libgdbm.so.3 -> libgdbm.so.3.0.0 -rwxr-xr-x 1 root root 19720 25. Jul 20:51 libgdbm.so.3.0.0 florian@powerstation /usr/lib $ Hope it helps :-) Florian
Sorry, my fault... same problems when emerging xemacs... checking for ncurses/term.h... no checking for ncurses/curses.h... no checking for database support checking for ndbm.h... yes checking for dbm_open in -lgdbm... no Error: Required GNU DBM support cannot be provided. !!! ERROR: app-editors/xemacs-21.4.15 failed. !!! Function src_compile, Line 161, Exitcode 1 !!! (no error message) No idea what to try next... Florian
same problems here. re-emerging gdbm-1.8.3 didn't remove the libgdbm.so.2.0.0, had to delete it manualy.
dropped the -a from the cp in the 1.8.3 ebuild
*** Bug 58350 has been marked as a duplicate of this bug. ***
*** Bug 19761 has been marked as a duplicate of this bug. ***
*** Bug 58370 has been marked as a duplicate of this bug. ***
*** Bug 59105 has been marked as a duplicate of this bug. ***
It seems that the ebuild now copies libgdbm.so.2 if there is any. The problem is, that the message of the ebuild concerning revdep-rebuild wasn't updated, and doesn't inform about the fact, that libgdbm.so.2 can be deleted.
If you are going to add 58350 as a dupe of this bug without actually understanding it, then it should be reopened. xemacs expects dbm_open to actually be in libgdbm not in libgdbm_compat.
