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

Tue, 22 Apr 2003 13:58:20 -0700

Patches item #590377, was opened at 2002-08-02 21:50
Message generated for change (Comment added) made by jhylton
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: Fixed
>Priority: 7
Submitted By: Matthias Klose (doko)
>Assigned to: Jeremy Hylton (jhylton)
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: Jeremy Hylton (jhylton)
Date: 2003-04-22 20:58

Message:
Logged In: YES 
user_id=31392

Rev 1.122 disables bsddb3 support for my build.  The
apparent problem is that it looks in /usr/include before
doing any other search.  On my RedHat 7.2 system,
/usr/include/db.h is a Berkeley DB 3 header file.  I have a
valid Berkeley DB 4.1.x install in /usr/local/BerkeleyDB.4.1/

Can we make this work by adding /usr/include to the list of
directories that are searched by the normal berkeley db
search process?  I'll try that.

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

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

Message:
Logged In: YES 
user_id=21627

Committed a similar patch as setup.py 1.222.

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

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

Message:
Logged In: YES 
user_id=21627

Can you please try the attached bsd.diff? It should find
db.h in the standard include directories, and use it if
possible.

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-11-01 14:02

Message:
Logged In: YES 
user_id=44345

> so why not use /etc/debian_version?

That's fine.  I didn't 
know it existed, having had no previous experience with 
Debian.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-01 09:41

Message:
Logged In: YES 
user_id=21627

Would you like to update your patch to implement that strategy?

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

Comment By: Matthias Klose (doko)
Date: 2002-11-01 07:58

Message:
Logged In: YES 
user_id=60903

so why not use /etc/debian_version?

the dpkg thing is useful to determine the correct db
version, or you grep the include file for the version number.

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-10-31 22:24

Message:
Logged In: YES 
user_id=44345

I was thinking more along the lines of a file we could look for.  
For example, on my Mandrake systems I have 
/etc/mandrake-release.  I suspect that pretty much rules out 
other Linux dialects (though what if someone converts to 
another version but doesn't format their disks?).

Testing 
the presence of dpkg isn't sufficient either.  Other systems 
can use it.  In fact, I have dpkg on my MacOSX system as a 
side-effect of being a fink user (http://fink.sf.net/).

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

Comment By: Matthias Klose (doko)
Date: 2002-10-31 22:13

Message:
Logged In: YES 
user_id=60903

two possibilities come to mind:
  dpkg -S /usr/include/db.h
prints:
  libdb4.0-dev: /usr/include/db.h

(or libdb3-dev, if the libdb3-dev package is installed).
Note that the installation of a libdb-dev package is not
required, so this command may return with an error.

I'm pretty sure, that dpkg only exists on Debian systems ;-)
or else test for the existance of the file
/etc/debian_version first.

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-10-27 15: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 15: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 14: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 22: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 21: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 21: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 21: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 13: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