# ldd /usr/lib/python2.5/lib-dynload/dbm.so linux-gate.so.1 => (0xffffe000) libdb1.so.2 => /usr/lib/libdb1.so.2 (0xb7f7e000) libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb7e47000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e2f000) libc.so.6 => /lib/libc.so.6 (0xb7cfa000) libdl.so.2 => /lib/libdl.so.2 (0xb7cf6000) libutil.so.1 => /lib/libutil.so.1 (0xb7cf2000) libm.so.6 => /lib/libm.so.6 (0xb7ccd000) /lib/ld-linux.so.2 (0x80000000) # ls -l /usr/lib/libdb1.so.2 -rwxr-xr-x 1 root root 56640 2007-01-09 06:04 /usr/lib/libdb1.so.2* # dep -F /usr/lib/libdb1.so.2 /usr/lib/libdb1.so.2: sys-libs/db-1.85-r3 The libdb1 link dependency is creeping in as -lndbm: ... building 'dbm' extension i686-pc-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -ggdb -O1 -O2 -O3 -pipe -march=athlon-xp -mmmx -msse -m3dnow -DHAVE_NDBM_H -I. -I/var/tmp/portage/dev-lang/python-2.5.1-r4/work/Python-2.5.1/./Include -I./Include -I. -I/usr/local/include -I/var/tmp/portage/dev-lang/python-2.5.1-r4/work/Python-2.5.1/Include -I/var/tmp/portage/dev-lang/python-2.5.1-r4/work/Python-2.5.1 -c /var/tmp/portage/dev-lang/python-2.5.1-r4/work/Python-2.5.1/Modules/dbmmodule.c -o build/temp.linux-i686-2.5/var/tmp/portage/dev-lang/python-2.5.1-r4/work/Python-2.5.1/Modules/dbmmodule.o i686-pc-linux-gnu-gcc -pthread -shared -Wl,--as-needed -L. -fno-strict-aliasing -DNDEBUG -ggdb -O1 -O2 -O3 -pipe -march=athlon-xp -mmmx -msse -m3dnow -I. -I./Include build/temp.linux-i686-2.5/var/tmp/portage/dev-lang/python-2.5.1-r4/work/Python-2.5.1/Modules/dbmmodule.o -L/usr/local/lib -L. -lndbm -lpython2.5 -o build/lib.linux-i686-2.5/dbm.so ... # ls -l /usr/lib/libndbm.so lrwxrwxrwx 1 root root 11 2007-01-09 06:04 /usr/lib/libndbm.so -> libdb1.so.2*
From Setup.py: # The standard Unix dbm module: if platform not in ['cygwin']: if find_file("ndbm.h", inc_dirs, []) is not None: # Some systems have -lndbm, others don't if self.compiler.find_library_file(lib_dirs, 'ndbm'): ndbm_libs = ['ndbm'] else: ndbm_libs = [] exts.append( Extension('dbm', ['dbmmodule.c'], define_macros=[('HAVE_NDBM_H',None)], libraries = ndbm_libs ) ) elif (self.compiler.find_library_file(lib_dirs, 'gdbm') and find_file("gdbm/ndbm.h", inc_dirs, []) is not None): exts.append( Extension('dbm', ['dbmmodule.c'], define_macros=[('HAVE_GDBM_NDBM_H',None)], libraries = ['gdbm'] ) ) elif db_incs is not None: exts.append( Extension('dbm', ['dbmmodule.c'], library_dirs=dblib_dir, runtime_library_dirs=dblib_dir, include_dirs=db_incs, define_macros=[('HAVE_BERKDB_H',None), ('DB_DBM_HSEARCH',None)], libraries=dblibs)) So, it will link against libndbm and thus against db-1* even if a later version of db is available.
Created attachment 140131 [details, diff] db-not-ndbm.patch Suggested patch. Testing now.
Yes, that works. Could this explain bug 192611?
Hi, I've changed your patch a little bit[1] to solve the automagic dependency problem. With this patch when gdbm USE flag is enabled, dbm module will be built using gdbm's ndbm compat libraries and when berkdb USE flag is enabled dbm will be built using berkdb. When both flags are enabled gdbm's compat library will be used to respect upstream's order in setup.py. Thanks for reporting ;) 1: http://overlays.gentoo.org/proj/python/browser/patches/2.5.1 /15_all_dbm_default_gdbm_compat.patch