[Python-Dev] Please give this patch for building bsddb a try
Barry A. Warsaw
barry@zope.com
Tue, 18 Jun 2002 22:34:17 -0400
>>>>> "SM" == Skip Montanaro <skip@pobox.com> 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],