[issue40505] getpath.c doesn't know about lib64

STINNER Victor added the comment: This issue is a duplicate of bpo-1294959. -- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> Add sys.platlibdir and configure --with-platlibdir to use /usr/lib64 on Fedora and SuSE

[issue40505] getpath.c doesn't know about lib64

Daniel Pflager added the comment: 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

[issue40505] getpath.c doesn't know about lib64

Marc-Andre Lemburg added the comment: 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,

[issue40505] getpath.c doesn't know about lib64

STINNER Victor added the comment: Hum, this issue seems to be specific to Fedora and SuSE. Did you open an issue on OpenSuSE bug tracker? > 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

[issue40505] getpath.c doesn't know about lib64

Marc-Andre Lemburg added the comment: Just to clarify: the CONFIG_SITE script on OpenSUSE causes configure to use lib64, not the Python configure script itself. -- ___ Python tracker

[issue40505] getpath.c doesn't know about lib64

New submission from Marc-Andre Lemburg : 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