After emerge -u world ran, my xemacs failed to load all the shared libs so I rebuilt gdbm and ran revdep-rebuild --soname libgdbm.so.2 And xemacs would still not run after that. So I unmerged it and tried to merge it and now I get a consistent error of 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) I have tried running the ebuild by hand but it fails there as well. I have walked through the relevant sounding bugs and forums and tried various solutions there (most having to do with athena widgets) and tried them and no go. Reproducible: Always Steps to Reproduce: 1.emerge xemacs 2. 3. Actual Results: 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) Expected Results: Successfully emerged xemacs and let me go back to work. Portage 2.0.50-r9 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040619-r0, 2.4.22-gentoo-r1) ================================================================= System uname: 2.4.22-gentoo-r1 i686 AMD Athlon(tm) processor Gentoo Base System version 1.5.1 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon -O3 -pipe -m3dnow -mmmx" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /etc/tomcat /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /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/qmail/control" CONFIG_PROTECT_MASK="/etc/afs/C /etc/afs/afsws /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon -O3 -pipe -m3dnow -mmmx" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apache2 apm arts athena avi berkdb bonobo cdr crypt cups doc encode esd ethereal evo fbcon flash foomaticdb gd gdbm gif gnome gphoto2 gpm gtk gtk2 gtkhtml guile imap imlib java jikes jpeg junit kde lcms libg++ libgda libwww mad mbox mikmod mmx motif mozilla mpeg mysql ncurses nls odbc oggvorbis opengl oss pam pda pdflib perl pic plotutils png postgres python qt quicktime readline ruby sasl sdl slang slp snmp spell ssl svga tcltk tcpd tetex tiff truetype usb wmf x86 xml xml2 xmms xv zeo zlib"
Created attachment 36160 [details] config.log from failed ru n.
Hi, same problem here. I came along from Bug 58220: http://bugs.gentoo.org/show_bug.cgi?id=58220 "libgdbm.so.2 with zero bytes size/ too short" which is fixed now, but still no chance to emerge / re-emerge xemacs! Same error, "Required GNU DBM support cannot be provided." Greetinge, Florian
Yup. Went through all the stuff in 58220 and it didn't help. Please don't make this a dupe of that.
I can offer you a (quick and dirty) way to compile xemacs. On my system I found a zero byte libgdbm.so.2.0.0, so I got rid of it: > emerge gdbm unmerge;emerge --oneshot gdbm Then emerge xemacs and stop (Ctrl-S) right after '>>> Source unpacked.' Edit line 4422f of configure.in in another window: /var/tmp/portage/xemacs-21.4.15/work/xemacs-21.4.15/configure.in:4422: AC_CHECK_LIB(gdbm, gdbm_open, [ with_database_gdbm=yes with_database_dbm=no libdbm="-lgdbm_compat -lgdbm"], [ and run autoconf: > cd /var/tmp/portage/xemacs-21.4.15/work/xemacs-21.4.15;autoconf-2.13 Continue (Ctrl-Q) the emerge. This hack gives a hint how to fix xemacs permanently. The old (version 2) libgdbm had a function dbm_open (no 'g') which is now in libgdbm_compat. The new (version 3) libgdbm only has a function gdbm_open and that is why configure fails to find dbm_open.
Hmmm. That suggestion didnt' work for me. BUT it gave met he idea of doing the following: LIBS="-lgdbm_compat -lgdbm" ebuild /usr/portage/app-editors/xemacs/xemacs-21.4.15.ebuild compile (after the normal steps of course). Still, it is a hack. The proper fix ought to get implemented somewhere.
Thanks, editing configure.in as suggested in comment #4 worked for me. I used ebuild xemacs-21.4.15.ebuild unpack cd /var/tmp/portage/xemacs-21.4.15/work/xemacs-21.4.15 edit configure.in as per comment #4 autoconf-2.13 ebuild xemacs-21.4.15.ebuild compile ebuild xemacs-21.4.15.ebuild install ebuild xemacs-21.4.15.ebuild qmerge
I forgot to add that I also did emerge -C gdbm emerge --oneshot gdbm sudo emerge -C openoffice-bin revdep-rebuild --soname libgdbm.so.2 took me a couple of iterations.
Re: Comment #4 and comment #6: Following these things worked for me, too. So I would suggest patching configure.in as in comment #4 and running autoconf-2.13 as in comment #6. I'm not sure how to modify the ebuild to add these steps, but doing it by hand worked.
Bug 32510 shows some work on this, as well as the problem of a zero-length libgdbm.so.2 showing up. This work-around worked for me: emerge --nodeps --oneshot =gdbm-1.8.0-r5 emerge xemacs emerge gdbm
*** This bug has been marked as a duplicate of 58220 ***
This bug is NOT a dupe. Please read down. dbm_open has moved out of libgdbm into libgdbm_compat. xemacs is not expecting it there, and requires the ebuild be hacked.
Created attachment 37403 [details, diff] enable xemacs to build using libgdbm 1.8.3 This patch + calling autoconf-2.13 in the ebuild compile step should fix the problem with needing libgdbm_compat.
Well xemacs-21.4.12 still borks on me... checking for dbm_open in -lgdbm... no Error: Required GNU DBM support cannot be provided. !!! ERROR: app-editors/xemacs-21.4.12 failed. !!! Function src_compile, Line 157, Exitcode 1 !!! (no error message) xyz@tux ~ $ emerge -p gdbm These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-libs/gdbm-1.8.3-r1 xyz@tux ~ $ ls -l /usr/lib/libgdbm* -rw-r--r-- 1 root root 33858 Aug 19 00:56 /usr/lib/libgdbm.a -rwxr-xr-x 1 root root 699 Aug 19 00:56 /usr/lib/libgdbm.la lrwxrwxrwx 1 root root 16 Aug 19 00:56 /usr/lib/libgdbm.so -> libgdbm.so.3.0.0 lrwxrwxrwx 1 root root 16 Aug 19 00:56 /usr/lib/libgdbm.so.3 -> libgdbm.so.3.0.0 -rwxr-xr-x 1 root root 25265 Aug 19 00:56 /usr/lib/libgdbm.so.3.0.0 -rw-r--r-- 1 root root 16426 Aug 19 00:56 /usr/lib/libgdbm_compat.a -rwxr-xr-x 1 root root 748 Aug 19 00:56 /usr/lib/libgdbm_compat.la lrwxrwxrwx 1 root root 23 Aug 19 00:56 /usr/lib/libgdbm_compat.so -> libgdbm_compat.so.3.0.0 lrwxrwxrwx 1 root root 23 Aug 19 00:56 /usr/lib/libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0 -rwxr-xr-x 1 root root 12708 Aug 19 00:56 /usr/lib/libgdbm_compat.so.3.0.0
Haven't tried the fix though... Better w8 for xemacs in portage to get fixed.. :)
This is still broken on 21.4.15-r1. Is anyone going to work on this?
*** Bug 61099 has been marked as a duplicate of this bug. ***
Created attachment 38132 [details] updated patch for xemacs-21.4.15-r1 to enable xemacs to build using libgdbm 1.8.3
Created attachment 38138 [details, diff] applies patch to configure.in to allow libgdm to be used and then calls autoconf-2.13
Ok so I created a <a href="http://bugs.gentoo.org/attachment.cgi?id=38132"> patch</a> for configure.in, put it in /usr/portage/app-editors/xemacs/files, also created a <a href="http://bugs.gentoo.org/attachment.cgi?id=38138">patch</a> for the xemacs-21.4.15-r1 ebuild which applies the configure.in patch and calls autoconf-2.13. xemacs then emerges for me. However, I'm not too clear on patch naming conventions, nor whether just calling autoconf-2.13 in the src_unpack as I did is ok (putting it in src_compile is suggested in comment 12, but that puts the ebuild changes in two places, and it was not clear to me that it was the better place). I would really like to be using the xemacs beta (currently at 21.5.17). Who knows, if I understand a little more of the ebuilds, others are interested and I'm not standing on someone's toes, I may put together an ebuild for it. (bugzilla is probably the wrong place for this suggestion - should shift to the forums I guess).
I can confirm that with this fix the ebuild emerges like a charm. would like to see it in portage tree soon
Included in -r2, thanks for all the help.
Note this breaks app-editors/xemacs-21.4.15-r2 if it's installed with ~x86 but gdbm isn't, because the xemacs won't work with gdbm-1.8.0. Could the ebuild be modified to make this explicit (that is, require sys-libs/gdbm-1.8.3)?
Modified the gdbm patch so that it builds against either 1.8.0 or 1.8.3.
Alright... I am having the same output error message and problems with xemacs 21.4.15-r3. I have been working on this for 3 days and It seems that the proposed are not applied during the configure process. How can I make sure that these patches are applied so that emerge works properly. Also, I upgraded to gdbm-1.8.3-r1. Dunno if that has anything to do with the problem. I am however able to manually compile and install the program. If do decide to excute the ebuild script manually, how do I unmerge the old version? Paul emerge info ortage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.200 50125-r1, 2.6.10-gentoo-r7 i686) ================================================================= System uname: 2.6.10-gentoo-r7 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Mar 19 2005, 02:37:27)] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r6 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/ 3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdow n /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/sh are/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /us r/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/te x/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /va r/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://ftp-mirror.internap.com/pub/gentoo/ http://gentoo.llarian .net/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.mirror. sdv.fr http://gentoo.tiscali.nl/gentoo/ http://www.gigaload.org/gentoo.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm arts avi berkdb bitmap-fonts bonobo cdr crypt cups cur l directfb divx4linux dvd dvdr emacs emboss encode esd evo fam flac font-server foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile i magemagick imlib ipv6 jack java jpeg kde libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png ppds python qt qui cktime readline sdl slang spell ssl svga tcltk tcpd tetex theora tiff truetype t ruetype-fonts type1-fonts wmf wxwindows xml xml2 xmms xv yahoo zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Your problem looks to be entirely unrelated, it just happens to give this error message when it can't find libXm also. Try this: emerge openmotif rm -rf /usr/include/Xm ln -s /usr/include/openmotif-2.2/Xm/ /usr/include/Xm emerge xemacs
*** Bug 70999 has been marked as a duplicate of this bug. ***
