Issue590377
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.
Created on 2002-08-02 21:50 by doko, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
setup.patch | doko, 2002-08-02 21:50 | |||
setup.patch | doko, 2002-10-21 21:14 | |||
bsd.diff | loewis, 2002-11-23 10:40 |
Messages (19) | |||
---|---|---|---|
msg40782 - (view) | Author: Matthias Klose (doko) * | Date: 2002-08-02 21:50 | |
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) |
|||
msg40783 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-10-13 13:06 | |
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. |
|||
msg40784 - (view) | Author: Matthias Klose (doko) * | Date: 2002-10-21 21:14 | |
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. |
|||
msg40785 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-10-21 21:42 | |
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. |
|||
msg40786 - (view) | Author: Matthias Klose (doko) * | Date: 2002-10-21 21:54 | |
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 ... |
|||
msg40787 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-10-21 22:11 | |
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. |
|||
msg40788 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2002-10-27 14:39 | |
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 |
|||
msg40789 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-10-27 15:12 | |
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. |
|||
msg40790 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2002-10-27 15:46 | |
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)? |
|||
msg40791 - (view) | Author: Matthias Klose (doko) * | Date: 2002-10-31 22:13 | |
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. |
|||
msg40792 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2002-10-31 22:24 | |
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/). |
|||
msg40793 - (view) | Author: Matthias Klose (doko) * | Date: 2002-11-01 07:58 | |
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. |
|||
msg40794 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-01 09:41 | |
Logged In: YES user_id=21627 Would you like to update your patch to implement that strategy? |
|||
msg40795 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2002-11-01 14:02 | |
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. |
|||
msg40796 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-23 10:40 | |
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. |
|||
msg40797 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-12-06 10:25 | |
Logged In: YES user_id=21627 Committed a similar patch as setup.py 1.222. |
|||
msg40798 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2003-04-22 20:58 | |
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. |
|||
msg40799 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2003-04-22 21:18 | |
Logged In: YES user_id=44345 Matthias, I don't see a reasonable way this can work. If you have db4 installed, it will still be found first because db4 is checked before db3. The best way to solve this would be to allow you to specify the search order. Would it be okay to set an environment variable to specify the search order? Something like PYBSDDB_VERSIONS=db3:db4 ; export PYBSDDB_VERSIONS If set, it would override the default setting of db_search_order in setup.py. |
|||
msg40800 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2003-04-22 22:02 | |
Logged In: YES user_id=31392 I take it back. It looks like the current code works. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:33 | admin | set | github: 36973 |
2002-08-02 21:50:49 | doko | create |