[Python-Dev] Getting python-bz2 into 2.3

Bob Kline bkline@rksystems.com
Mon, 2 Dec 2002 21:47:12 -0500 (EST)


On Sat, 30 Nov 2002, Guido van Rossum wrote:

> More testing is always welcome; if you could test-drive the
> instructions in PCbuild/readme.txt for Tcl/Tk and Sleepycat Berkeley
> DB on multiple platforms that would be super.

The instructions for building Tcl and Tk worked as written with no
problems (though I would have no idea where to begin with the XXX
questions, such as "Should we compile with OPTS=threads?").  The project
file for the _tkinter module also worked without any hitches, but I
don't see a test suite (no surprise for a GUI-based module) and I have
no clue about how to test it or even get some of my simple _tkinter
program to run.  I'm so far out of my depth here with respect to Tcl/Tk
that I won't waste list bandwidth to pursue this any further.

As for the Berkeley DB package, that too built without any difficulties.
The instructions conclude:

==============================  snip  ==============================
    XXX We're actually linking against Release_static\libdb40s.lib.
    XXX This yields the following warnings:
"""
Compiling...
_bsddb.c
Linking...
   Creating library ./_bsddb.lib and object ./_bsddb.exp
LINK : warning LNK4049: locally defined symbol "_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free" imported
LINK : warning LNK4049: locally defined symbol "_fclose" imported
LINK : warning LNK4049: locally defined symbol "_fopen" imported
_bsddb.pyd - 0 error(s), 4 warning(s)
"""
    XXX This isn't encouraging, but I don't know what to do about it.
==============================  snip  ==============================

I did a little poking around, and found that the problem is that the
static library against which the _bsddb package is built is compiled
with the -MT option, which causes the multi-threaded runtime libraries
to be statically linked into libdb40s.lib, hence the warnings.  The
warnings should probably be taken seriously, because I think they mean
that we would end up with (for example) two sets of static heap control
information.

The instructions in PCBuild/readme.txt were actually a little confusing,
because right before the part I just quoted above tells us to "[c]hoose
configuration "db_buildall - Win32 Release", and build db_buildall.exe."
That version uses the -MD compilation option, which uses the DLL version
of the runtime libraries (which is what we want), but it creates a DLL
for libdb40 instead of a library which can be statically linked into
_bsddb.pyd.  So it looks as there are two ways to eliminate the warnings
above:

 1. Use the DLL version of libdb40 and link to its import library.
 2. Create a third configuration for the underlying Berkeley DB
    library, using the -MD compilation option, but building a
    statically linkable library instead of a DLL.

I would have assumed that the second option was needed, because I
assumed that Python wouldn't want to drag around lots of DLLs for the
various packages that get installed, but then I noticed that the
_tkinter package is doing just that, so I guess I'm not sure.

If the second option is used, it should presumably be done with the
cooperation of the folks behind the Berkeley DB library, so it wouldn't
be necessary to recreate the third configuration by hand each time a new
release of the library came out.

Finally, I was reluctant to dig any further into this package because I
read at the top of the instructions:

    "XXX The Sleepycat release we use will probably change before
     XXX 2.3a1."

and I didn't know whether that referred to a version upgrade or a
complete replacement of the underlying DB engine with some other
library, which would make any further work throwaway.

-- 
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com