[issue40854] Allow overriding sys.platlibdir: add PYTHONPLATLIBDIR env var

2020-06-11 Thread Sandro Mani
Change by Sandro Mani : -- pull_requests: +19995 pull_request: https://github.com/python/cpython/pull/20799 ___ Python tracker <https://bugs.python.org/issue40

[issue40947] Replace PLATLIBDIR macro with config->platlibdir

2020-06-11 Thread Sandro Mani
Change by Sandro Mani : -- keywords: +patch pull_requests: +19994 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20799 ___ Python tracker <https://bugs.python.org/issu

[issue40947] Replace PLATLIBDIR macro with config->platlibdir

2020-06-11 Thread Sandro Mani
New submission from Sandro Mani : Followup of bpo-40854, there is one remaining usage of PLATLIBDIR which should be replaced by config->platlibdir. -- components: Interpreter Core messages: 371260 nosy: smani priority: normal severity: normal status: open title: Replace PLATLIB

[issue40854] [Patch] Allow overriding sys.platlibdir

2020-06-08 Thread Sandro Mani
Sandro Mani added the comment: Many thanks! - I'll ask downstream to carry the patch for the 3.9 cycle, so I'm ok with closing. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40854] [Patch] Allow overriding sys.platlibdir

2020-06-05 Thread Sandro Mani
Sandro Mani added the comment: I'm on Fedora. My use case is for the mingw-python package I maintain there, see [1] for the full details. I believe (though I haven't investigated) that the previous downstream lib64 patch behaved slightly differently, or that something else between python

[issue40854] [Patch] Allow overriding sys.platlibdir

2020-06-03 Thread Sandro Mani
New submission from Sandro Mani : You can currently point the python interpreter to a different install say via export PYTHONHOME= export PYTHONPATH=/lib/python3.9 python3 With the newly added platlibdir [1], if python was configured with platlibdir=lib64, this will break because

[issue40777] _datetimemodule.c:3328:16: error: initializer element is not constant

2020-05-26 Thread Sandro Mani
New submission from Sandro Mani : Hitting this when attempting to cross-compile python-3.9 to mingw: /builddir/build/BUILD/Python-3.9.0b1/Modules/_datetimemodule.c:3328:16: error: initializer element is not constant 3328 | .tp_base = _Type, Indeed PyTuple_Type does not have static

[issue16754] Incorrect shared library extension on linux

2013-01-28 Thread Sandro Mani
Sandro Mani added the comment: So, from what I can see, historically the SO extension was taken from sysconfig.py, see [1] lines 24 and 60. Then, the CCompiler class got overhauled, and the value was hardcoded to .so, see [2], but the compiler.shared_lib_extension = SO statement remained

[issue16754] Incorrect shared library extension on linux

2012-12-23 Thread Sandro Mani
New submission from Sandro Mani: I'm using Python3 as available in Fedora rawhide (python3-3.3.0-2.fc19.x86_64). Attempting to build a project using python3/distutils, I noticed that find_library_file would not find any library at all. Some investigation showed that this was due to the fact