This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Old bsddb version picked by setup.py
Type: Stage:
Components: Distutils Versions: Python 2.3
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: loewis Nosy List: gregory.p.smith, joshhoyt, loewis
Priority: normal Keywords:

Created on 2003-07-02 19:39 by joshhoyt, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
setup.diff joshhoyt, 2003-07-02 19:39 Patch to correctly choose the version of Berkeley DB to link against
Messages (7)
msg16821 - (view) Author: Josh Hoyt (joshhoyt) Date: 2003-07-02 19:39
I have two versions of Berkeley DB in the standard
include path. The code in setup.py finds the newer
version first (db4) and then finds the older version
(db3) later in scanning standard includes. This means
that the bsddb module is built against the older rather
than the newer version.

The attached patch to setup.py records all standard
headers that are found and lets the db_search_order
list choose which version of the library to link against.
msg16822 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-06 09:46
Logged In: YES 
user_id=21627

I'm not quite sure how this could ever happen. Are you
saying that you have two different versions of db.h, both on
your standard search path? In what specific locations?

This is asking for trouble, and it might be better if
setup.py would actively reject that scenario, refusing to
build _bsddb.
msg16823 - (view) Author: Josh Hoyt (joshhoyt) Date: 2003-07-07 02:29
Logged In: YES 
user_id=693077

There is a system Berkeley DB library and I have a locally
built newer Berkeley DB library. When building Python, I
added my local build to the include path and to the library
path.

Am I missing a more explicit way of selecting the library
short of editing Setup in the Modules directory?
msg16824 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-07 05:00
Logged In: YES 
user_id=21627

Can you please be more explicit? What operating system are
you using, what compiler, how did you add something to the
include path, what was the version of BerkeleyDB that was
installed, what was the version that you installed yourself,
and where did you install it?

In short, you shouldn't add something to the include path.
For gcc, I don't even see how you *could* add something to
the include path.
msg16825 - (view) Author: Josh Hoyt (joshhoyt) Date: 2003-07-07 16:29
Logged In: YES 
user_id=693077

I am running Debian GNU/Linux, unstable, with GCC 3.3.1.

I added the following to my environment prior to building
Python:
LDFLAGS=-L${HOME}/local/lib
CFLAGS-I${HOME}/local/include

My local build of Berkeley DB is version 4.1.25, and the
system version is 3.2.9.

I hope that makes the situation clear.
msg16826 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-10-18 09:51
Logged In: YES 
user_id=21627

I see. Please notice that setting CFLAGS prior to
compilation is not really supported, so I recommend that you
don't set CFLAGS - BerkeleyDB 4.1 should still be found in
/usr/local, or (preferred) /usr/local/BerkeleyDB.4.1
msg16827 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2006-04-12 19:24
Logged In: YES 
user_id=413

the rewrite of the BerkeleyDB version selection code in
setup.py i did a while back (last year) should have taken
care of this.

prior to that it could indeed pick non-matching include and
library files.
History
Date User Action Args
2022-04-10 16:09:40adminsetgithub: 38777
2003-07-02 19:39:46joshhoytcreate