Repository navigation
getpath.c doesn't know about lib64 #84685
Description
| BPO | 40505 |
|---|---|
| Nosy | @malemburg, @vstinner, @pflagerd |
| Superseder |
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 = None
closed_at = <Date 2020-12-14.08:51:39.051>
created_at = <Date 2020-05-04.21:51:07.816>
labels = ['interpreter-core', '3.8', 'type-bug', '3.7']
title = "getpath.c doesn't know about lib64"
updated_at = <Date 2020-12-14.08:51:39.050>
user = 'https://github.com/malemburg'bugs.python.org fields:
activity = <Date 2020-12-14.08:51:39.050>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2020-12-14.08:51:39.051>
closer = 'vstinner'
components = ['Interpreter Core']
creation = <Date 2020-05-04.21:51:07.816>
creator = 'lemburg'
dependencies = []
files = []
hgrepos = []
issue_num = 40505
keywords = []
message_count = 6.0
messages = ['368086', '368087', '368088', '368092', '382928', '382963']
nosy_count = 3.0
nosy_names = ['lemburg', 'vstinner', 'pflagerd']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = '1294959'
type = 'behavior'
url = 'https://bugs.python.org/issue40505'
versions = ['Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8']
Activity
malemburg commentedon May 4, 2020
On platforms which configure identifies as bi-arch platform, libdir is set to $[exec_prefix}/lib64, which results in the C extensions to get installed in e.g. /usr/local/lib64/python3.8/lib-dynload/.
However, the getpath.c routines use a fixed "lib/python" VERSION (see https://github.com/python/cpython/blob/3.8/Modules/getpath.c#L1200) path to build sys.path. As a result, the built Python binary cannot load the builtin C extensions.
A work-around on OpenSUSE is to set CONFIG_SITE="" when configuring Python. This disables the bi-arch support and has libdir default to ${exec_prefix}/lib again.
Looking at the master branch, this may already have been fixed for 3.9, since a PLATLIBDIR variable is used instead. The patch would have to be backported to earlier Python versions as well.
malemburg commentedon May 4, 2020
Just to clarify: the CONFIG_SITE script on OpenSUSE causes configure to use lib64, not the Python configure script itself.
vstinner commentedon May 4, 2020
Hum, this issue seems to be specific to Fedora and SuSE. Did you open an issue on OpenSuSE bug tracker?
Yeah, this issue looks like a duplicate of bpo-1294959 which has been fixed. I suggest to close the issue. I had to a new attribute to the sys module, not like the thing that we can do in a stable version.
malemburg commentedon May 4, 2020
No, I have not opened a bug report on OpenSUSE. Since the OS uses bi-arch throughout, using lib64 is the natural thing to use for libdir on the OS.
I think the issue lies with getpath.c only, since it makes an assumption about the libdir config value, which doesn't necessarily hold in practice. The libdir config value can be changed via the standard --libdir configure parameter, so getpath.c should really not assume that the default setting is always used.
Having a variable in Python 3.9 is nice, but perhaps we can still make Python 3.7 and 3.8 work as well.
The correct approach to building the full lib_python path is not to use exec_prefix + "/lib/python" + VERSION, but instead to use libdir + "/python" + VERSION (which corresponds to the Makefile variable BINLIBDEST). libdir would have to be taken from the config variable LIBDIR.
pflagerd commentedon Dec 13, 2020
Python-3.9.1 OpenSUSE 15.1
While ./configure --with-platlibdir=lib64 does work-around the problem on OpenSUSE by putting everything into lib64/, this is not the default behavior. In other words, should Python-3.9.1 be built on OpenSUSE 15.1 without --with-platlibdir=lib64, the behavior described in this bug report occurs.
Not everyone building Python-3.9.1 on OpenSUSE will take the time to research this and end up finding https://bugs.python.org/issue1294959 (as I did after considerable effort).
Intuitively, doesn't one expect configure to work this kind of thing out (and if it can't, warn the user)?
vstinner commentedon Dec 14, 2020
This issue is a duplicate of bpo-1294959.