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

2020-12-14 Thread STINNER Victor


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-12-12 Thread Daniel Pflager


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 
--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)?

--
nosy: +pflagerd

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-04 Thread Marc-Andre Lemburg


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, 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-04 Thread STINNER Victor


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 backported 
> to earlier Python versions as well.

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.

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-04 Thread Marc-Andre Lemburg


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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-04 Thread Marc-Andre Lemburg


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 "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.

--
components: Interpreter Core
messages: 368086
nosy: lemburg
priority: normal
severity: normal
status: open
title: getpath.c doesn't know about lib64
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com