"SM" == Skip Montanaro
writes:
SM> If you build the bsddb module on a Unix-like system (that is, SM> you use configure and setup.py to build the interpreter and it SM> attempts to build the bsddb module), please give the new patch SM> attached to SM> http://python.org/sf/553108 Skip, Apologies for taking so long to respond to this thread. I'm still digging out from my move. Basically what you have in cvs works great, except for one small necessary addition. If you build Berkeley DB from source, it's going to install it in something like /usr/local/BerkeleyDB.3.3 by default. Why they choose such a bizarre location, I don't know. The problem is that unless your sysadmin hacks ld.so.conf to add /usr/local/BerkeleyDB.X.Y/lib onto your standard ld run path, bsddbmodule.so won't be linked in such a way that it can actually resolve the symbols at run time. I don't think it's reasonable to require such system hacking to get the bsddb module to link properly, and I think we can do better. Here's a small patch to setup.py which should fix things in a portable way, at least for *nix systems. It sets the envar LD_RUN_PATH to the location that it found the Berkeley library, but only if that envar isn't already set. I've tested this on RH7.3 and MD8.1 -- all of which I have a from-source install of BerkeleyDB 3.3.11. Seems to work well for me. I'm still having build trouble on my RH6.1 system, but maybe it's just too old to worry about (I /really/ need to upgrade one of these days ;). -------------------- snip snip -------------------- building 'bsddb' extension gcc -g -Wall -Wstrict-prototypes -fPIC -DHAVE_DB_185_H=1 -I/usr/local/BerkeleyDB.3.3/include -I. -I/home/barry/projects/python/./Include -I/usr/local/include -I/home/barry/projects/python/Include -I/home/barry/projects/python -c /home/barry/projects/python/Modules/bsddbmodule.c -o build/temp.linux-i686-2.3/bsddbmodule.o In file included from /home/barry/projects/python/Modules/bsddbmodule.c:25: /usr/local/BerkeleyDB.3.3/include/db_185.h:171: parse error before `*' /usr/local/BerkeleyDB.3.3/include/db_185.h:171: warning: type defaults to `int' in declaration of `__db185_open' /usr/local/BerkeleyDB.3.3/include/db_185.h:171: warning: data definition has no type or storage class /home/barry/projects/python/Modules/bsddbmodule.c: In function `newdbhashobject': /home/barry/projects/python/Modules/bsddbmodule.c:74: warning: assignment from incompatible pointer type /home/barry/projects/python/Modules/bsddbmodule.c: In function `newdbbtobject': /home/barry/projects/python/Modules/bsddbmodule.c:124: warning: assignment from incompatible pointer type /home/barry/projects/python/Modules/bsddbmodule.c: In function `newdbrnobject': /home/barry/projects/python/Modules/bsddbmodule.c:182: warning: assignment from incompatible pointer type -------------------- snip snip -------------------- Sigh. Anyway thanks! You've improved the situation immensely. -Barry -------------------- snip snip -------------------- Index: setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.94 diff -u -r1.94 setup.py --- setup.py 17 Jun 2002 17:55:30 -0000 1.94 +++ setup.py 19 Jun 2002 01:01:19 -0000 @@ -507,6 +507,13 @@ dblibs = [dblib] raise found except found: + # A default source build puts Berkeley DB in something like + # /usr/local/Berkeley.3.3 and the lib dir under that isn't + # normally on LD_RUN_PATH, unless the sysadmin has hacked + # /etc/ld.so.conf. Setting the envar should be portable across + # compilers and platforms. + if 'LD_RUN_PATH' not in os.environ: + os.environ['LD_RUN_PATH'] = dblib_dir if dbinc == 'db_185.h': exts.append(Extension('bsddb', ['bsddbmodule.c'], library_dirs=[dblib_dir],