When using this flag configure failed on "checking for dbm_open in -lgdbm_compat using extra libs -lgdbm...". Once I removed --as-needed from my LDFLAGS it found it and the compile went through completely. I changed nothing else in between so it's obvious that it's the culprit. emerge --info for completeness sake: Portage 2.1.1_pre4-r4 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, 2.6.17-gentoo-r2 x86_64) ================================================================= System uname: 2.6.17-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.12.4 Last Sync: Thu, 10 Aug 2006 11:20:01 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.16 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -msse3 -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -O3 -msse3 -fvisibility-inlines-hidden -ftree-vectorize" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE@euro" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X a52 aac alsa avi bash-completion berkdb bitmap-fonts bzip2 cdr cli crypt cups dbus dlloader dri dvb dvd eds elibc_glibc emboss encode ffmpeg foomaticdb fortran gif gpm gstreamer gtk2 hal imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kde kdeenablefinal kdehiddenvisibility kdenewldflags kernel_linux linguas_de lzw lzw-tiff mad mp3 mpeg ncurses nls nptl nptlonly ogg opengl pam pcre pdflib perl png pppd python qt qt3 qt4 quicktime readline reflection samba sdl session spell spl sse3 ssl tcpd theora tiff truetype-fonts type1-fonts unicode usb userland_GNU userlocales video_cards_nv vorbis x264 xorg xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_RSYNC_EXTRA_OPTS
Please note that the database support of xemacs-21.4.19 as it is in portage is considered broken. Detection does not work well, especially not with newer versions of berkdb and gdbm and berkdb are jumbled together in a strange way so that the berkdb flag may in fact result in gdbm being used. A newer version of the xemacs ebuild with updated database patches is available from my subversion overlay: http://moving-innovations.com/svn/xemacs/ This version splits out berkdb and gdbm support and has additional configure support for newer versions of berkdb. I could run configure there using USE="gdbm berkdb" LDFLAGS="-Wl,--as-needed" emerge xemacs Hopefully this version of the ebuild will be in portage soon as I am currently on track to become a developer.
i have a similar error, Im unsure if it should be part of the same bug or not. configure passes fine ( even with gentoos official tree ) but both gentoos and your patched versions screw up at the very last link ( at least for me ) gcc -c -O2 -march=i686 -mtune=athlon-xp -pipe -ggdb -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include dump-id.c gcc -O2 -march=i686 -mtune=athlon-xp -pipe -ggdb -Wl,-O1,-z,combreloc,--as-needed,--sort-common,--enable-new-dtags -L/usr/X11R6/lib -Wl,-export-dynamic -o xemacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o dumper.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-motif.o realpath.o inline.o linuxplay.o nas.o esd.o miscplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o gpmevent.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o lastfile.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o dump-id.o ../lwlib/liblw.a -laudio -lXm -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lgdbm -lgdbm_compat -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lasound -lpq -lldap -llber -lm -lutil /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_open' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_errno' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_close' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `_gdbm_memory' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_firstkey' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_nextkey' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_fetch' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `_gdbm_file' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `_gdbm_fetch_val' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_delete' /usr/X11R6/lib/libgdbm_compat.so: undefined reference to `gdbm_store' collect2: ld returned 1 exit status make[1]: *** [xemacs] Error 1 make[1]: Leaving directory `/tmp/..var/portage/xemacs-21.4.19-r4/work/xemacs-21.4.19/src' make: *** [src] Error 2 taking --as-needed out of that makes it work, which I do not understand, as i thought the --as-needed failures were generally due to an incorrect order of operands. I tried playing with order of operands ( ie: switching placement of FILE.o and -lLIB instructions ) to no avail, so Im guessing theres some intrinsic weirdness in gdbm :/
I've looked into this a bit more today and it seems to me that the culprit is actually libgdbm_compat, which is not properly linked against libgdbm. This should be fixed in gdbm. Interestingly for me linking works fine, but I get an undefined symbol gdbm_errno when trying to run the resulting executable.
Created attachment 95818 [details, diff] gdbm-1.8.3-as-needed.patch This patch fixes the gdbm_compat.la file to properly include gdbm when linking. This fixes problems with --as-needed for applications that want to link to gdbm_compat (like xemacs). The patch needs to be added to the sys-libs/gdbm ebuild.
Ran into this today so.. Status?
It's not a problem in xemacs but rather in gdbm as mentioned in comment 4. It should probably be reassigned to the gdbm people, but I can't do this.
Reassigning this to base-system as this has to be fixed in gdbm, not in xemacs.
not exactly ... if you build statically, xemacs will still fall apart it needs to be -lgdbm_compat -lgdbm
This is now fixed in xemacs 21.4.19-r2. SpanKY, thanks for the feedback on how to deal with this properly.
