[issue40777] _datetimemodule.c:3328:16: error: initializer element is not constant
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 = &PyTuple_Type, Indeed PyTuple_Type does not have static storage, so I suppose this [1] applies. [1] https://stackoverflow.com/a/3025106/1338788 -- components: Build messages: 369965 nosy: smani priority: normal severity: normal status: open title: _datetimemodule.c:3328:16: error: initializer element is not constant type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40854] [Patch] Allow overriding sys.platlibdir
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 i.e. the site-packages dir as returned by `sysconfig.get_paths()` will use lib64 and not lib as the other install may be using. This PR adds the possibility to override the platlibdir via environment variable. Full rationale: [2]. [1] https://github.com/python/cpython/pull/8068 [2] https://src.fedoraproject.org/rpms/python3.9/pull-request/10 -- components: Interpreter Core messages: 370655 nosy: smani priority: normal severity: normal status: open title: [Patch] Allow overriding sys.platlibdir versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40854] [Patch] Allow overriding sys.platlibdir
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-3.8 and earlier and python-3.9 changed, in that I didn't have lib64 appear in the site packages path previously when invoking python as detailed in [1], whereas it now does. [1] https://src.fedoraproject.org/rpms/python3.9/pull-request/10#comment-0 -- ___ Python tracker <https://bugs.python.org/issue40854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40854] [Patch] Allow overriding sys.platlibdir
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/issue40854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40947] Replace PLATLIBDIR macro with config->platlibdir
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 PLATLIBDIR macro with config->platlibdir ___ Python tracker <https://bugs.python.org/issue40947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40947] Replace PLATLIBDIR macro with config->platlibdir
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/issue40947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40854] Allow overriding sys.platlibdir: add PYTHONPLATLIBDIR env var
Change by Sandro Mani : -- pull_requests: +19995 pull_request: https://github.com/python/cpython/pull/20799 ___ Python tracker <https://bugs.python.org/issue40854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16754] Incorrect shared library extension on linux
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 that libraries were searched with
the ".cpython-33m.so" extension. Even more investigation showed that the
library extension was read being overridden by the one defined in the
/usr/lib64/python3.3/config-3.3m/Makefile shipped by python3-libs. See
below for the detailed analysis. The python-versioned extension
obviously makes no sense for regular shared objects which are not python
binary modules, so this is clearly wrong. As a workaround I patched
sysconfig.py to comment out customize_compiler::235
(compiler.shared_lib_extension =
so_ext, see below), recompiled python (all tests still pass), and things seem
to work.
Detailed analysis:
setup.py:
def _find_library_file(self, library):
return self.compiler.find_library_file(self.compiler.library_dirs,
library)
---
In function
/usr/lib64/python3.3/distutils/unixcompiler.py at find_library_file::266:
shared_f = self.library_filename(lib, lib_type='shared')
In function
/usr/lib64/python3.3/distutils/ccompiler.py at library_filename::882:
ext = getattr(self, lib_type + "_lib_extension")
-> Where does shared_lib_extension get defined?
* At /usr/lib64/python3.3/distutils/ccompiler.py::66
shared_lib_extension = None -> default for abstract class
* At /usr/lib64/python3.3/distutils/unixcompiler.py::77
shared_lib_extension = ".so" -> this is the correct value
* In function
/usr/lib64/python3.3/distutils/sysconfig.py at customize_compiler::235
by /usr/lib64/python3.3/distutils/sysconfig.py at customize_compiler::235
compiler.shared_lib_extension = so_ext
by /usr/lib64/python3.3/distutils/sysconfig.py at customize_compiler::194
(cc, cxx, opt, cflags, ccshared, ldshared, so_ext, ar, ar_flags) = \
get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
'CCSHARED', 'LDSHARED', 'SO', 'AR', 'ARFLAGS'))
by /usr/lib64/python3.3/distutils/sysconfig.py at get_config_vars::530
526 global _config_vars
527 if _config_vars is None:
528 func = globals().get("_init_" + os.name) # -> os.name = posix
529 if func:
530 func() # -> _init_posix, populates _config_vars
by /usr/lib64/python3.3/distutils/sysconfig.py at _init_posix::439
435 g = {}
436 # load the installed Makefile:
437 try:
438 filename = get_makefile_filename() #
/usr/lib64/python3.3/config-3.3m/Makefile
439 parse_makefile(filename, g)
...
476 global _config_vars
477 _config_vars = g # -> _config_vars["SO"] = ".cpython-33m.so"
by /usr/lib64/python3.3/config-3.3m/Makefile::122
SO= .cpython-33m.so
--
assignee: eric.araujo
components: Distutils
messages: 177979
nosy: eric.araujo, smani, tarek
priority: normal
severity: normal
status: open
title: Incorrect shared library extension on linux
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue16754>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16754] Incorrect shared library extension on linux
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, presumably oversight. So technically, this is also affecting python 2.x, though in that case it does not make any difference, since python2 does not use versioned so-names for binary modules. [1] http://hg.python.org/cpython/file/2802fb52e99b/Lib/distutils/unixccompiler.py [2] http://hg.python.org/cpython/rev/7922d08426ca -- ___ Python tracker <http://bugs.python.org/issue16754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
