Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=95818) [details]
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.