[ python-Bugs-764839 ] Old bsddb version picked by setup.py
SourceForge.net
noreply at sourceforge.net
Wed Apr 12 21:24:12 CEST 2006
Bugs item #764839, was opened at 2003-07-02 12:39
Message generated for change (Comment added) made by greg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Martin v. Löwis (loewis)
Summary: Old bsddb version picked by setup.py
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: Gregory P. Smith (greg)
Date: 2006-04-12 12:24
Message:
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.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-10-18 02:51
Message:
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
----------------------------------------------------------------------
Comment By: Josh Hoyt (joshhoyt)
Date: 2003-07-07 09:29
Message:
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.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-06 22:00
Message:
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.
----------------------------------------------------------------------
Comment By: Josh Hoyt (joshhoyt)
Date: 2003-07-06 19:29
Message:
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?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-06 02:46
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470
More information about the Python-bugs-list
mailing list