Update to v3.14.5#209
Merged
Merged
Conversation
Co-authored-by: Naveen M K <[email protected]> Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]>
This is used throughout the Python code but is not defined when compiling with Mingw-w64 compilers, so define it. In MSVC these are defined in PC/pyconfig.h, we have to define it manually because pyconfig.h is created by autotools. Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]> Co-authored-by: Naveen M K <[email protected]>
Co-authored-by: Алексей <[email protected]>
Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]>
Largefile is supported on Windows. Co-authored-by: Naveen M K <[email protected]> Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]>
Co-authored-by: Naveen M K <[email protected]>
Also, build `nt` module instead of `posix` when compiling with MINGW. Co-authored-by: Naveen M K <[email protected]> Co-authored-by: Алексей <[email protected]>
Co-authored-by: Алексей <[email protected]>
Co-authored-by: Naveen M K <[email protected]>
Add PYD_PLATFORM_TAG to distinguish C extensions built with different MinGW toolchain configurations. The tag follows the format: mingw_<cpu_arch>_<c_runtime>_<toolchain> Where: - cpu_arch: x86_64, i686, aarch64, or armv7 - c_runtime: ucrt or msvcrt - toolchain: gnu or llvm This prevents loading extensions built with incompatible configurations. Co-authored-by: Naveen M K <[email protected]>
Co-authored-by: Алексей <[email protected]>
Try to match the format defined in pycore_importdl.h for Windows
MS_DLL_ID is used for sys.winver and Windows registry keys
Co-authored-by: Алексей <[email protected]>
Co-authored-by: Алексей <[email protected]> Co-authored-by: Naveen M K <[email protected]>
Co-authored-by: Алексей <[email protected]> Co-authored-by: lovetox <[email protected]>
Co-authored-by: Алексей <[email protected]> Co-authored-by: Naveen M K <[email protected]>
This would possibly fix building wheels when mingw python is used and would be unique to each python same as EXT_SUFFIX. Signed-off-by: Naveen M K <[email protected]>
Co-authored-by: Алексей <[email protected]> Co-authored-by: Naveen M K <[email protected]>
This is the case used in MINGW Co-authored-by: Алексей <[email protected]>
Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]>
Just like with MSVC. This fixes a test in test_ctypes.
Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]>
This should avoid mixing of user site-packages between python from various environments. Previously, the user site-packages should be located at `~/.local/lib/python3.12` for all environment including 32-bits variants which caused problems with 64-bit trying to load 32-bit extensions. Now this path will be changed to `~/.local/lib/python3.12-<platform tag here>`, for example, in CLANG64 this would be `~/.local/lib/python3.12-mingw_x86_64_ucrt_llvm`. Fixes #40
Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]>
so there is no bash required to run it on Windows
os needs ntpath.sep, so define it before importing os Co-authored-by: Алексей <[email protected]> Co-authored-by: Christoph Reiter <[email protected]> Co-authored-by: cat <[email protected]> Co-authored-by: Naveen M K <[email protected]>
The casing and pathseps have to match, so a cross compiler on Linux find the files. Co-authored-by: Martin Storsjö <[email protected]>
for example the wmi module
Invalid "Libs:" value Also it contains "-L." which is only used at build time by makesetup and shouldn't be exposed. python#138800
This is fallout from LIBPYTHON not inluding -L. anymore
Like on Linux we provide python3.x globally, so make sure those also exist in the venv, so when python3.x is run the venv version is launched and not the global one.
copy the logic from callproc.c
So we get different names for debug and free threaded builds
setuptools doesn't play along
value copied from the MSVC build config
We require autoreconf to run for the build, and we use Ubuntu 24.04 for llvm which only ships 2.71. It looks like there wasno real reason for upstream to require it, so this should be fine.
it's tied to the build system used and not Windows, and it's used in various places we use such as python-config, so improve the condition.
It passing "notfound" as the path parameter and not as the fallback, so this never could have worked with cross compiling. Fixes CXX being set to "g++" instead of the cross compiler. Should be upstreamed.
dependency libs might add system search paths first, so make sure we link to libpython before that. Otherwise we link to the system libpython if it already exists.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
range diff: