[Patches] [ python-Patches-590377 ] db4 include not found

[noreply@sourceforge.net]

Patches item #590377, was opened at 2002-08-02 16:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: db4 include not found

Initial Comment:
setup.py looks for the db4 library in /usr/lib, but
doesn't look for the header in /usr/include (as you
find it on Debian unstable)


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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-10-27 09:46

Message:
Logged In: YES 
user_id=44345

It's clear we can't blindly add '/usr/include' to 
db_try_this['db4']['incdirs'] and 'db' to 
db_try_this['db4']['libs'].  Is there some way to 
unambiguously detect from setup.py that Python is being 
built on a Debian system and that we are not dealing with an 
installation of db1 (which I still refuse to enable without 
manual intervention)?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-27 09:12

Message:
Logged In: YES 
user_id=21627

/usr/include/db.h is not a symlink; it is the file itself.
You cannot have multiple bsddb development packages
(libdbX-dev) installed, because they conflict with each
other. /usr/lib/libdb.so exists and is a symlink to the
installed shared library.

The file in question isn't actually db.h (for current
bsddbmodule.c), but db_185.h, of course.

As for base+patch: Sure, Debian already uses such a patch.
Matthias is the Debian maintainer of Python, and asks us (as
upstream) to include his patch.

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-10-27 08:39

Message:
Logged In: YES 
user_id=44345

Is /usr/include/db.h a symlink to some other file on Debian 
which is version-specific?  If so, I'd be happy to add that 
directory to the list searched.  How does Debian structure 
its directories to allow multiple versions of Berkeley db to be 
installed simultaneously?  If /usr/include/db.h is the 
location of the include file, is /usr/lib/libdb.{so,a} the 
location of the library?

The original (db1) versions of 
Berkeley DB generally had db.h in /usr/include.  This 
version is, unfortunately, both broken and still in use.  Other 
vendors allow multiple versions of the library to be installed, 
and use a version-specific directory naming scheme to 
keep things sorted out.  Debian could do the same.

No 
matter how strongly you believe /usr/include should be 
searched, I'm not going to add it by default and risk the 
chance that other peoples' installs break (silently) as a 
result.  Please read the comments related to db1 in 
setup.py.  (Search for bsddb.)

Final thought here...  
Doesn't Debian have and base+patch sort of system?  To 
install on Debian, all that would need to be done is develop a 
Debian-specific patch which adds /usr/include to the incdirs 
key and something like 'db' to the libs key in the db4 
section.

Skip

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-21 17:11

Message:
Logged In: YES 
user_id=21627

As a bug report, I would close this as "Won't fix", pointing
you to the option of not using setup.py, but compiling the
module through Modules/Setup. 

I'd prefer to get a patch, but that should be one that works
on all systems. This one breaks on systems where
/usr/include/db.h is not a bsddb 4 header file.

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

Comment By: Matthias Klose (doko)
Date: 2002-10-21 16:54

Message:
Logged In: YES 
user_id=60903

> - Doesn't it cause -I/usr/include be added to the
>   compilation statement?

yes, that's not correct

> - Why is that done for db4 and not db3?

On Debian only one libdb-dev package can be installed at
build time. I assure with the build dependencies that I get
the correct one.

> - How can we know what bsddb version /usr/include/db.h
>   belongs to? Guessing that it is db4 is error-prone, so it  
>   might be, in fact, better not to find that file.

maybe grep for DB_VERSION_MAJOR in the file?

I admit, this issue should be a bug report, not a patch ...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-21 16:42

Message:
Logged In: YES 
user_id=21627

Ok, I admit that the patch might be needed; I think it is
quite incorrect, though: 

- Doesn't it cause -I/usr/include be added to the
compilation statement?

- Why is that done for db4 and not db3?

- How can we know what bsddb version /usr/include/db.h
belongs to? Guessing that it is db4 is error-prone, so it
might be, in fact, better not to find that file.

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

Comment By: Matthias Klose (doko)
Date: 2002-10-21 16:14

Message:
Logged In: YES 
user_id=60903

Martin, you're closing reports very quickly ;-) What makes
you think the problem is solved? The code doesn't search
/usr/include for db.h.

Updated patch included.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-13 08:06

Message:
Logged In: YES 
user_id=21627

The patch is out-of-date, and appears to be unnecessary. I'm
rejecting it - if you still think something needs to be
done, please submit a new patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470