Summary: | libgdbm_compat.so.3 isn't linked to libgdbm.so | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Justin Lecher (RETIRED) <jlec> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cdavis5x, raphexion |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 340080 | ||
Attachments: | dev-lang/python-2.6.4 |
Description
Justin Lecher (RETIRED)
2009-12-28 13:07:20 UTC
Created attachment 214378 [details]
dev-lang/python-2.6.4
build.log
Might be related to bug 165268 is this during a bootstrap? Do you have gdbm installed? It looks like libgdbm_compat.so bails for missing symbols, which more looks like this is not specific. It is always like that. I have gdbm installed. Python only builds "automagically" the dbm lib if gdbm is installed ( bad behaviour !!). So when I unemerge gdbm it installes fine, after reemergeing gdbm it is broken again. The patch from bug 143580 fixed it. @python folks: seems we need -lgdbm here (In reply to comment #7) I use --as-needed and I have never reproduced such a bug with Python. I see "-lgdbm -lgdbm_compat" in build log. I don't have those problems on clean bare gentoo, but found them here. It just looks like --as-needed is broken in this respect, and I have no idea how to fix it. If you find clues, please reopen this bug. *** Bug 331369 has been marked as a duplicate of this bug. *** reopening due to dupe "/usr/lib/libgdbm_compat.so.3: undefined symbol: _gdbm_memory" would be a bug in sys-libs/gdbm. except that gdbm_compat already needs gdbm and that provides gdbm_memory. since it only appears to fail on prefix systems, i guess it's back on their portable heads to figure out why that environment is breaking things. $ readelf -d /usr/lib/libgdbm_compat.so | grep gdbm.so 0x0000000000000001 (NEEDED) Shared library: [libgdbm.so.3] $ readelf -s /usr/lib/libgdbm.so | grep gdbm_memory 31: 0000000000205160 16 OBJECT GLOBAL DEFAULT 24 _gdbm_memory and libgdbm_compat is linked in the correct order when emerging gdbm: x86_64-pc-linux-gnu-gcc -shared dbminit.lo delete.lo fetch.lo store.lo seq.lo close.lo dbmopen.lo dbmdelete.lo dbmfetch.lo dbmstore.lo dbmseq.lo dbmclose.lo dbmdirfno.lo dbmpagfno.lo dbmrdonly.lo -Wl,--rpath -Wl,/usr/lib64 -L/usr/lib64 -L/var/tmp/portage/sys-libs/gdbm-1.8.3-r4/image//usr/lib64 -lgdbm -Wl,-O1 -Wl,-soname -Wl,libgdbm_compat.so.3 -o .libs/libgdbm_compat.so.3.0.0 objects first followed by -lgdbm Work around applied. %% svn di python-2.6.5-r2.ebuild Index: python-2.6.5-r2.ebuild =================================================================== --- python-2.6.5-r2.ebuild (revision 58609) +++ python-2.6.5-r2.ebuild (working copy) @@ -185,6 +185,9 @@ } src_configure() { + # Apparently, no one knows how to solved this as-needed failure. + # bug 298674 Apply workaround for now. + use prefix && append-ldflags $(no-as-needed) # Disable extraneous modules with extra dependencies. if use build; then export PYTHON_DISABLE_MODULES="dbm _bsddb gdbm _curses _curses_panel readline _sqlite3 _tkinter _elementtree pyexpat" ok, on an ELF system at hand, $ readelf -d /usr/lib/libgdbm_compat.so | grep gdbm.so results in nothing. So that would mean this is a problem in gdbm on Prefix. Removing python, as it seems to have nothing to do with it. gdbm-1.8.3-r04.1 has the correct needed entry, building python also succeeds with this version. (undoing the hack in the ebuild, of course) |