this bug is somewhat related to bug #120099 at least to the last comment on it the problem is that python built with USE="berkdb doc gdbm ipv6 ncurses readline ssl tk -bootstrap -build -nocxx -ucs2" will have dbm module disabled. there are two problems here - on stock emerge, the build log will have the following lines: building 'dbm' extension i686-pc-linux-gnu-gcc -pthread -DNDEBUG -march=athlon-xp -O2 -pipe -fPIC -fno-strict-aliasing -DHAVE_GDBM_NDBM_H -I. -I/var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4/./Include -I/var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4/Include -I/var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4 -c /var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4/Modules/dbmmodule.c -o build/temp.linux-i686-2.4/dbmmodule.o i686-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -fno-strict-aliasing -DNDEBUG -march=athlon-xp -O2 -pipe build/temp.linux-i686-2.4/dbmmodule.o -L/usr/local/lib -lgdbm -o build/lib.linux-i686-2.4/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.4/dbm.so: undefined symbol: dbm_firstkey and this could be resolved with patch like this one http://developer.momonga-linux.org/viewvc/trunk/pkgs/python/python-2.5-gdbm_compat.patch?view=markup&pathrev=13357 (I'll attach a similar one) the problem is that this is not enough as it will lead to the following: building 'dbm' extension i686-pc-linux-gnu-gcc -pthread -DNDEBUG -march=athlon-xp -O2 -pipe -fPIC -fno-strict-aliasing -DHAVE_GDBM_NDBM_H -I. -I/var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4/./Include -I/var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4/Include -I/var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4 -c /var/tmp/portage/dev-lang/python-2.4.4/work/Python-2.4.4/Modules/dbmmodule.c -o build/temp.linux-i686-2.4/dbmmodule.o i686-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -fno-strict-aliasing -DNDEBUG -march=athlon-xp -O2 -pipe build/temp.linux-i686-2.4/dbmmodule.o -L/usr/local/lib -lgdbm_compat -lgdbm -o build/lib.linux-i686-2.4/dbm.so *** WARNING: renaming "dbm" since importing it failed: /usr/lib/libgdbm_compat.so.3: undefined symbol: _gdbm_memory the problem is the unresolved symbols in libgdbm_compat, which is treated in bug #165263 in these both cases I have /usr/lib/python2.4/lib-dynload/dbm_failed.so after applying both of the patches from bug #165263 and the one, which I'll upload here - dbm module builds correctly and could be imported
Created attachment 109117 [details, diff] python-2.4.4-dbm.patch patch, which adds libgdbm_compat to the libraries linked in the dbm module
Works for me. I guess the gdbm fixes mentioned in comment #1 solves this.
No it does not resolve anything. I haven't commented earlier as it was a new system and patched from my overlay, but now the new update to: [ebuild R ] dev-lang/python-2.4.4-r4 USE="berkdb gdbm ipv6 ncurses readline ssl tk -bootstrap -build -doc -examples -nocxx -nothreads -ucs2" 0 kB breaks it again: ls -l /usr/lib64/python2.4/lib-dynload/*dbm* -rwxr-xr-x 1 root root 15216 May 16 03:36 /usr/lib64/python2.4/lib-dynload/dbm_failed.so -rwxr-xr-x 1 root root 18600 May 16 03:36 /usr/lib64/python2.4/lib-dynload/gdbm.so and undefined symbol: PyExc_TypeError (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyExc_KeyError (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyType_Type (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: _Py_NoneStruct (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyDict_SetItemString (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_firstkey (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_open (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: _PyObject_New (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyString_FromStringAndSize (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: Py_FindMethod (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyArg_ParseTuple (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_fetch (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyString_FromString (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyInt_FromLong (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_close (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyModule_GetDict (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_nextkey (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_store (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyErr_NewException (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyList_Append (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyArg_Parse (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: Py_InitModule4 (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyObject_Free (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyErr_SetString (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyList_New (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: PyErr_SetFromErrno (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) undefined symbol: dbm_delete (/usr/lib64/python2.4/lib-dynload/dbm_failed.so) libpthread.so.0 => /lib/libpthread.so.0 (0x00002ab9f4189000) libc.so.6 => /lib/libc.so.6 (0x00002ab9f43a3000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) Ignoring Py* symbols (this are provided by python itself and will be resolved from there, when it loads the extension) and taking for example dbm_delete and connecting this to the patch: nm -D --defined-only /usr/lib64/libgdbm.so |grep dbm_delete 0000000000001dc0 T gdbm_delete and nm -D --defined-only /usr/lib64/libgdbm_compat.so |grep dbm_delete 0000000000001334 T dbm_delete As you see there is no possibility to link to gdbm, which is used in the original as the symbols do not exist there and --as-needed, throws away the so as it is not used - which could be seen on the output of ldd -r. The symbols needed are in gdbm_compat and this is what the patch makes - changes gdbm for gdbm_compat+gdbm.
This bug seems to be fixed in dev-lang/python:2.5.