Update to v3.11.10 #177
Merged
Update to v3.11.10 #177
Conversation
This file contains 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
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: lovetox <8661218+lovetox@users.noreply.github.com>
Co-authored-by: Naveen M K <naveen521kk@gmail.com> Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
This is used throughout the Python code but is not defined when compiling with Mingw-w64 compilers, so define it. Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Largefile is supported on Windows. Co-authored-by: Naveen M K <naveen521kk@gmail.com> Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Co-authored-by: Naveen M K <naveen521kk@gmail.com>
Also, build `nt` module instead of `posix` when compiling with MINGW. Co-authored-by: Naveen M K <naveen521kk@gmail.com> Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Naveen M K <naveen521kk@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
`ws2_32` is required when building that module
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
This is the case used in MINGW Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com> Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com> Co-authored-by: cat <cat@wolfgirl.org> Co-authored-by: Naveen M K <naveen521kk@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
Co-authored-by: Алексей <alexey.pawlow@gmail.com>
also move `gethostname` to that check
while building `_multiprocessing` extension also, always build that module on win32
they are guarded by dlopen being present, but if module loading is enabled is more correct.
this is required for venv to work properly
they don't seems to handle `/` as path separator correctly
- Use function available in original msvcrt.dll _wdupenv_s -> _wgetenv_s fread_s -> fread - Add a test for checking the new launchers
also, fix finding prefix when in a venv
Instead of just calling normpath in abspath just call normpath on all the config results. This makes sure we don't change getpath.py too much and still cover all outputs. This fixes sys.exec_prefix not matching sys.prefix, see #142
this gets added as first element in sys.path. use normpath to make sure it uses the right path separator
…gets In cpython-mingw-3.10, this was part of a patch named "allow static tcltk". Co-authored-by: Алексей <alexey.pawlow@gmail.com>
This provides the limited ABI as a separate DLL, forwarding to the real one. This makes linking with "-lpython3" work. Fixes #147
…extensions For some reason the code assumes that relative paths are build paths prepends the system dirs after relative paths in the existing list. We only uses absolute paths though, and I don't understand why it even tries to do that. So just append the system dirs instead. This fixes the build trying to link against the system Python DLL in case it happens to be installed.
This looks for DLL names in the import table but while with MSVC the DLL is named python311.dll in our case it is named libpython3.11.dll. Adjust the strings and lengths accordingly.
It seems like in case the path passed to it is absolute, but contains forward slashes then LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR does not work and DLLs in the same directory as the extension are not considered. This occurs in our fork because in MSYS2-mode the extension loader will normalize to forward slashes before. Normalize everything to backslashes again before passing it to LoadLibraryExW. Fixes #151
…lues for `LIBDIR`
When building shared modules (*.pyd) for MinGW, they link against the import library for the main python (e.g. -lpython3.11). When linking shared modules on Linux, this doesn't happen, but those shared libraries are linked with undefined references which then are fulfilled by the host process when they are loaded. Add a dependency to make sure that $(LDLIBRARY), e.g. libpython$(LDVERSION).dll.a, exists before starting to build the shared modules. Previously, if libpython$(LDVERSION).dll.a didn't exist when the shared modules were linked, some of them failed to link, but this wasn't reported as an error in the build, and a later invocation of setup.py would retry building them, which then would succeed. E.g. there was a seemingly benign race condition in the build. However, in some rare cases, the race condition no longer was benign. The build also produces a corresponding static library, $(LIBRARY), e.g. libpython$(VERSION)$(ABIFLAGS).a - which in the end would be named similarly, libpython3.11.a, when $(LDLIBRARY) would be libpython3.11.dll.a. If the static library exists but the import library doesn't, then most modules would still fail to link, but a few ones wouldn't (select, _multiprocessing, _overlapped and _socket). The ones that did succeed linking with the static library would crash at runtime though. By making sure that the right, intended library to fulfill the linker parameter "-lpython3.11" exists before building the shared modules, we avoid the whole race condition that in some rare cases could produce a Python build that crashes at runtime. For Linux targets, this extra dependency is unnecessary, but should not cause other problems ($(LDLIBRARY) is set to the same as $(LIBRARY) if not building any shared library). This fixes MSYS2 cpython-mingw issue #162.
assumes Unix paths on Windows
gcc 14 changed `incompatible-pointer-types` from warning to error for now, make it as warning to avoid build failure
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Simple rebase, no conflicts