[Python-bugs-list] [Bug #117464] clash with BSD db when building

[noreply@sourceforge.net]

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: fleury
Assigned to : akuchling
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h
missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the
/usr/include/db1/db.h file, but on my system, /usr/include/db.h points to
db3/db.h which does not define the same set of values, and does not
compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

Follow-Ups:

Date: 2001-Feb-16 02:47
By: twouters

Comment:
Assigned to Andrew to see if he can rewrite the bsddb detection code in
distutils, like described in bug #132600.


-------------------------------------------------------

Date: 2001-Jan-20 08:51
By: twouters

Comment:
Apologies for not responding sooner, but I'm not sure how to fix this in
autoconf, except for redoing the test entirely, and PEP-229 shows good
promise for fixing this. The answer is pretty complicated anyway. db_185.h
comes with BSDDB 2 and 3, and under RedHat 7, BSDDB 1, 2 and 3 can all be
installed at the same time, in /usr/local/{db1,db2,db3}. 

I think the right fix would be to remove the autoconf stuff, and just check
for the existance of db_185.h in /usr/include/db3 or /usr/include/db2, or
the existance of db.h in /usr/include/db1, and then link with the right
library (which can be libdb-3.1.so, libdb2.so and libdb1.so on my RedHat
system. Confusing, isn't it ? :)

I'll see if I can fix something up, unless someone else does it before
me.

-------------------------------------------------------

Date: 2001-Jan-02 09:13
By: montanaro

Comment:
Reassigned to Thomas Wouters because I think he has RH7.0.
I can't test this directly and haven't had time to investigate.  My
apologies for waiting so long to slough
this off to someone else.


-------------------------------------------------------

Date: 2000-Nov-06 08:40
By: montanaro

Comment:
This is going to require a bit of effort.  My current scheme for detecting
whether bsddb can be built/linked or not relies on the presence or absence
of db.h and/or db_185.h.  If db_185.h is present, libdb v.2 is assumed.  If
only db.h is present, libdb v.1 is assumed.

Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three
versions installed at once.  I don't yet know if bsddbmodule.c can be
built/linked with v.3 (seems likely, since db_185.h still existts), but
even if it can, configure will have to grovel around in db.h looking for
DB_VERSION_MAJOR.  If it doesn't exist, we have v.1.  If it does exist, its
value will determine what version > 1 we have.

I imagine for an autoconf whiz this will be a simple task, but it's more of
a challenge than I have time for at the moment.  Anyone want to take this
on?

-------------------------------------------------------

Date: 2000-Oct-23 18:13
By: fleury

Comment:
Well, I also tried at home, where I have a vanilla RH7.0 and it compiles
perfectly.
The reported bug was on a RH6.2->RH7.0 upgraded machine.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470