Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.7k
gh-98636: Fix detecting gdbm_compat for _dbm module#98643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
mgorny commentedNov 4, 2022
Ping. |
mgorny commentedDec 7, 2022
Another ping. It would be really nice to have this fixed. |
Uh oh!
There was an error while loading.Please reload this page.
Fix the gdbm_compat library detection logic to actually check for-lgdbm_compat independently of the ndbm detection. This fixes the buildfailure with `--with-dbmliborder=gdbm`, and implicit fallback to ndbmwith the default value.
mgorny commentedDec 31, 2022
@erlend-aasland, updated as requested. |
erlend-aasland commentedJan 11, 2023
Does this need a backport? |
mgorny commentedJan 11, 2023
Unless I'm mistaken, no. The issue was introduced inec5e253, and FWICS this in 3.12 only. |
erlend-aasland commentedJan 11, 2023
Thanks, and sorry for the delay! If you want to pursue the AC refactorings discussed, please open an issue/PR. |
mgorny commentedJan 12, 2023
Thank you! I'm happy enough having the immediate problem fixed. |
Uh oh!
There was an error while loading.Please reload this page.
Fix the gdbm_compat library detection logic to actually check for
-lgdbm_compat independently of the ndbm detection. This fixes the build
failure with
--with-dbmliborder=gdbm, and implicit fallback to ndbmwith the default value.
--with-dbmliborder=gdbmno longer satisfies_dbm#98636