Repository navigation
Need to rework the dbm lib/include selection process #48837
Description
| BPO | 4587 |
|---|---|
| Nosy | @smontanaro, @doko42 |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/smontanaro'
closed_at = <Date 2009-05-01.09:44:57.519>
created_at = <Date 2008-12-08.01:22:50.402>
labels = ['type-bug', 'build']
title = 'Need to rework the dbm lib/include selection process'
updated_at = <Date 2009-05-01.09:44:57.517>
user = 'https://github.com/smontanaro'bugs.python.org fields:
activity = <Date 2009-05-01.09:44:57.517>
actor = 'doko'
assignee = 'skip.montanaro'
closed = True
closed_date = <Date 2009-05-01.09:44:57.519>
closer = 'doko'
components = ['Build']
creation = <Date 2008-12-08.01:22:50.402>
creator = 'skip.montanaro'
dependencies = []
files = ['12290', '13285', '13645']
hgrepos = []
issue_num = 4587
keywords = ['patch', 'needs review']
message_count = 11.0
messages = ['77280', '77283', '77314', '77342', '77348', '77463', '77469', '83379', '85700', '86818', '86876']
nosy_count = 4.0
nosy_names = ['skip.montanaro', 'doko', 'hawking', 'rpetrov']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4587'
versions = ['Python 2.6', 'Python 3.0', 'Python 3.1', 'Python 2.7']
Activity
smontanaro commentedon Dec 8, 2008
Fixing bpo-4483 resulted in adding an extra header file check for
gdbm-based header files when the gdbm library was found. This caused
problems for Roumen Petrov. In considering the problems he encountered I
decided we probably need to provide users some more flexibility when
deciding which libraries and header files to use when building the dbm
module (or _dbm on 3.0). For example, the current hard-coded perform checks
in this order: ndbm, gdbm, BerkDB. What if the system has hdbm installed
but the builder wants to use the BerkDB compatibility API?
This ticket is to track the discussion and come up with a suitable system.
smontanaro commentedon Dec 8, 2008
Roumen, can you take a look at (and try) the attached patch? It uses
an environment variable, PYDBMLIBORDER to define the order of libraries
to check for dbm build suitability. If not specified it defaults to
"ndbm:gdbm:bdb".
rpetrov commentedon Dec 8, 2008
About my environment :
a) gdbm library, with header gdbm.h, without *ndbm.h
b) "Berkeley DB" many versions but the last is 4.4 I think
only "Berkeley DB" 4.7
I will check later the patch but at first look is expected to fail. Lets
see
http://svn.python.org/view/python/trunk/Modules/dbmmodule.c?rev=67614&view=auto
. This module don't include gdbm.h header. I expect linux build to fail
with error "No ndbm.h available!"
I could test patch later when I get access to build environment.
Did you like I to test what is result (linux build) when header gdbm.h
is included in module ?
rpetrov commentedon Dec 8, 2008
I confirm my expectation:
in case 'elif cand == "gdbm":' the if statement for "gdbm.h" has to be
removed. This header don't provide dbm/ndbm compatible
structure/function names.
If setup is without 'if find_file("gdbm.h"...' statement dbm module is
build successfully and test_dbm pass.
smontanaro commentedon Dec 8, 2008
Roumen> I confirm my expectation:
Roumen> in case 'elif cand == "gdbm":' the if statement for "gdbm.h" has to be
Roumen> removed. This header don't provide dbm/ndbm compatible
Roumen> structure/function names.
Roumen> If setup is without 'if find_file("gdbm.h"...' statement dbm module is
Roumen> build successfully and test_dbm pass.
Right. Dumb move on my part. New patch attached.
Skip
rpetrov commentedon Dec 9, 2008
ok for patch
smontanaro commentedon Dec 9, 2008
Thanks Roumen. Can I get a verdict on this approach from one of the
main Python developers? I'm thinking a better way to control this
would be to add a --flag to the build command to control the search
order.
hawking commentedon Mar 9, 2009
Here's how Gentoo and Exherbo does it.
Note this links to gdbm_compat by default and prevents automagic
dependencies.
doko42 commentedon Apr 7, 2009
here is an updated patch, adding a new configure option
--with-dbmliborder, and checking the config args in setup.py.
this is the same approach as taken with the --with-system-libffi option.
doko42 commentedon Apr 29, 2009
checked in my patch as rev72107 on the trunk. Will apply it for py3k
tomorrow.
doko42 commentedon May 1, 2009
applied on the py3k branch as well