bpo-35705: Added support of libffi in _ctypes for windows 10 ARM64#11497
bpo-35705: Added support of libffi in _ctypes for windows 10 ARM64#11497ossdev07 wants to merge 2 commits intopython:3.6from
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
ossdev07
changed the title
ossdev07
changed the title
ossdev07
changed the title
|
@ossdev07 The PR needs to be raised against master branch since this is a new enhancement and 3.6 is in security fixes only mode. Please use 35705 instead of 3705 in the PR title which is the correct issue number for this PR. Thanks |
ossdev07
changed the title
… windows 10 ARM64 [3.6]bpo-35705:(pythonGH-11497) 1. added a separate library project for libffi for ARM64, which is refered by _ctypes in case of ARM64 compiler 2. compile out libffi's win32_x86 files in case of arm64 platform, as these files are provided with library. pythonGH-11497 Signed-off-by: ossdev <[email protected]>
zware
left a comment
zware
left a comment
There was a problem hiding this comment.
@ossdev07, thanks for the PR! This is something that we will definitely want to support.
However, as @tirkarthi mentioned, this change should be made against master; 3.6 is closed to anything but security fixes at this point. I'm not even certain this would be backported to 3.7 at this point. As such, I'm closing this PR.
As far as the approach taken here, I would prefer to do things differently. We've long wanted to remove Modules/_ctypes/libffi_msvc/, which is a very ancient version of libffi and completely unmaintained. Instead of adding Modules/_ctypes/libffi_msvc_arm64, it would be much better to finish off the work of treating libffi just like openssl, bzip2, or lzma, where our build process actually pulls in the original source for the library and builds it alongside Python. GH-3806 is a start on that, but neither @zooba nor I have had a chance to get back to it yet. I'm sure I speak for Steve as well when I say we'd be thrilled if you took that PR as a starting point and ran with it :)
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
5 participants
refered by _ctypes in case of ARM64 compiler
files are provided with library.
Signed-off-by: ossdev [email protected]
https://bugs.python.org/issue3705