Repository navigation
Detect dbm and gdbm dependencies in configure.ac #89910
Description
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/tiran'
closed_at = <Date 2021-11-10.19:58:15.692>
created_at = <Date 2021-11-08.10:27:28.586>
labels = ['type-feature', 'build', '3.11']
title = 'Detect dbm and gdbm dependencies in configure.ac'
updated_at = <Date 2022-04-04.08:29:49.316>
user = 'https://github.com/tiran'bugs.python.org fields:
activity = <Date 2022-04-04.08:29:49.316>
actor = 'arhadthedev'
assignee = 'christian.heimes'
closed = True
closed_date = <Date 2021-11-10.19:58:15.692>
closer = 'christian.heimes'
components = ['Build']
creation = <Date 2021-11-08.10:27:28.586>
creator = 'christian.heimes'
dependencies = []
files = []
hgrepos = []
issue_num = 45747
keywords = ['patch']
message_count = 6.0
messages = ['405940', '405941', '405946', '405953', '406053', '406127']
nosy_count = 5.0
nosy_names = ['ronaldoussoren', 'christian.heimes', 'pablogsal', 'erlendaasland', 'arhadthedev']
pr_nums = ['29467', '32299']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue45747'
versions = ['Python 3.11']Metadata
Metadata
Assignees
Projects
- Status
Activity
tiran commentedon Nov 8, 2021
setup.py jumps through hoops to detect gdbm, gdbm_compat, ndbm, and bdb (libdb) build dependencies. I propose to simplify our support matrix and detect all dependencies in configure.ac.
gdbmmodule.c uses gdbm_open() API, which is provided by gdbm.h and libgdbm
dbmmodule.c uses the dbm_open() API, which can be provided by a combination of headers and shared libraries.
setup.py makes some wrong assumption in regards of libgdbm. The shared library libgdbm does not provide the dbm_open() API on any system I tested. libgdbm_compat is always required. Linking with libgdbm is not needed. libgdbm_compat depends on and wraps libgdbm.
setup.py also performs additional steps to locate old versions of libdb-3.x and libdb-4.x. libdb-5.3 has been around for a decade. Even CentOS 7 and Debian oldoldstable ship with libdb version 5.3 and don't offer libdb version 4. I propose to remove support for libdb 4 and libdb 3.
tiran commentedon Nov 8, 2021
Pablo's macOS ARM64 buildbot does not find libdb-5.3 although it has db.h: https://buildbot.python.org/all/#/builders/721/builds/97/steps/2/logs/stdio
macOS X86-64 buildbot has libdb-5.3: https://buildbot.python.org/all/#/builders/311/builds/332/steps/2/logs/stdio
ronaldoussoren commentedon Nov 8, 2021
dbm_open is in libc on macOS. likely due to being in SUSv2.
The implementation in libc appears to be suboptimal (for example: bpo-33074), although I wouldn't teach configure.ac to ignore the system version of the library.
tiran commentedon Nov 8, 2021
Thanks Ronald. I was not aware that macOS has dbm_open in libc.
AC_CHECK_LIB() always tries to link with an external library. The macro should skip the symbol from libc. Could you please run the PR locally and upload your config.log?
erlend-aasland commentedon Nov 9, 2021
AC_SEARCH_LIBS() will search libc before checking external libraries, FWIW.
tiran commentedon Nov 10, 2021
New changeset 0a9f695 by Christian Heimes in branch 'main':
bpo-45747: Detect gdbm/dbm dependencies in configure (GH-29467)
0a9f695