[Python-Dev] Distutils confuses Berkeley DB and dbm?

Barry A. Warsaw barry@zope.com
Fri, 31 May 2002 10:25:54 -0400

>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:

    SM> The bsddb build problem is essentially that some (many? most? 
    SM> all?) Linux distributions ship with multiple versions of the
    SM> Berkeley DB library now.  To make matters worse, they separate
    SM> the shared libraries (in base rpms) from the include files (in
    SM> -devel rpms).  On my Mandrake system that gives you six
    SM> possible rpms to install: dbX and dbX-devel, for X in {1,2,3}.
    SM> Based on the way distutils checks for libraries and include
    SM> files (which I believe is mostly my fault), if you have only
    SM> one of any given pair of such rpms, like Barry, you might wind
    SM> up compiling with one version of the library and trying to
    SM> link with a different version.

It's worse than that.  On my MD8.2 system, I've got at least 4
versions of Berkeley installed:

    db1-1.85-7mdk + db1-devel-1.85-7mdk
    db2-2.4.14-5mdk + db2-devel-2.4.14-5mdk
    libdb3.3-3.3.11-7mdk + libdb3.3-devel-3.3.11-7mdk

Those are all installed with a fairly beefy package selection, but
nonetheless stock packages.  Then I've got Berkeley DB 3.3.11
installed from source sitting in its default installation spot of
/usr/local/BerkeleyDB.3.3 and 4.0.14 sitting in
/usr/local/BerkeleyDB.4.0 ... sigh!

I wouldn't argue if you said it was a mess. ;)  So what do we do?

I still think that pybsddb is a worthy candidate for inclusion in the
standard library and it should link against 3.3.11 out of the box.  I
believe the cvs snapshot of pybsddb links against 4.0.14 as well.

Then there's this bug


Maybe we should lock bsddbmodule down to Berkeley 1.85 and then pull
pybsddb (which exports as module bsddb3) for Berkeley 3.3.11.  If
there's a clamor for it, I suppose we could fake a bsddb2 and bsddb4
for those major versions of Berkeley.