python
bpo-46498: Add new triplets for loongarch64
Add new triplets for loongarch64, please review, thanks! https://bugs.python.org/issue46498
https://bugs.python.org/issue46498
Signed-off-by: Zhang Na [email protected] Reviewed-by: Wang Xuerui [email protected] Reviewed-by: Wu Xiaotian [email protected] Reviewed-by: Zhu Yaliang [email protected]
Hello, and thanks for your contribution!
I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).
CLA Missing
Our records indicate the following people have not signed the CLA:
@loongson-zn
For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.
If you have recently signed the CLA, please wait at least one business day before our records are updated.
You can check yourself to see if the CLA has been received.
Thanks again for the contribution, we look forward to reviewing it!
Every change to Python requires a NEWS entry.
Please, add it using the blurb_it Web app or the blurb command-line tool.
Most changes to Python require a NEWS entry.
Please add it using the blurb_it web app or the blurb command-line tool.
LoongArch toolchain conventions -- official documentation instructions, please review, thanks! @corona10 @erlend-aasland
@loongson-zn I will take a look, but it may takes some times to review from the view of supporting this platform is proper. Please keep patient
@loongson-zn I will take a look, but it may takes some times to review from the view of supporting this platform is proper. Please keep patient
Thanks，this is debian documentation about LoongArch, we need cpython support LoongArch.
llvm 16.0.0 、kernel 5.19、gcc 13.1、binutils 2.40 、glibc 2.36 and many other projects already support LoongArch.
On the other hand, I find python in the Gentoo , . /python3.11-config --extension-suffix output is .cpython-311.so, but to maintain consistency with other architectures, the output should be .cpython-311-loongarch64-linux-gnu.so. So, I think this commit should be merged as soon as possible to avoid more new questions continue to arise.
Oleg, the build label is for issues, not PRs. For PRs, we clearly see which part of the code base is touched from the diff view, so build is superfluous; it only clutters the GH issue/PR search, contributing to noise. I consider the topic- labels likewise[^1]. The same logic applies: we clearly see that a PR is a topic-argument-clinic if it touches clinic.py; the clutter argument also applies.
[^1]: though the devguide says they are for issues/PRs, they are de facto used for issues, not PRs
the build label is for issues, not PRs.
I consider the topic- labels likewise.
Thank you, got it.
llvm 16.0.0 、kernel 5.19、gcc 13.1、binutils 2.40 、glibc 2.36 and many other projects already support LoongArch. On the other hand, I find python in the Gentoo ,
. /python3.11-config --extension-suffixoutput is.cpython-311.so, but to maintain consistency with other architectures, the output should be.cpython-311-loongarch64-linux-gnu.so. So, I think this commit should be merged as soon as possible to avoid more new questions continue to arise.
@erlend-aasland @corona10 @arhadthedev As far as I know, LoongArch is promoting community work in Debian and Yocto. Can we consider accelerating the progress of Python's support work?
Sorry for the late response: Please consider that you can meet the requirement of PEP-11
At least for tier 3, you would need at least one core dev and a reliable buildbot first.
Thanks，this is debian documentation about LoongArch, we need cpython support LoongArch.
My suggestion is, how about sending a downstream patch to Debian first?
Sorry for the late response: Please consider that you can meet the requirement of PEP-11
At least for tier 3, you would need at least one core dev and a reliable buildbot first.
PEP-11 is for platforms, not architectures?
PEP-11 is for platforms, not architectures?
- Who will maintain the loongarch64-unknown-linux-gnu ?
- How can we verify the code for loongarch64-unknown-linux-gnu ?
I am sure that such requirements should be checked before we accept the related code from the maintenance cost view.
And we requested similar requirements to Windriver team too : https://mail.python.org/pipermail/python-dev/2019-January/156031.html
@erlend-aasland cc @loongson-zn
But on the other hand, if this is the only patch that they will need, I am okay to accept the patch anyway.
And we requested similar requirements to Windriver team too : https://mail.python.org/pipermail/python-dev/2019-January/156031.html
AFAICS, that's also about a platform, not an architecture ;) Anyways, this is getting too offtopic :)
My two cents:
Who will maintain the loongarch64-unknown-linux-gnu?
Aside from the Loongson teams, there is an active community around LoongArch (also Telegram user group) with multiple porters and power users willing to help. I'm heavily involved in and contributed to many upstream projects' LoongArch support, if it helps.
How can we verify the code for loongarch64-unknown-linux-gnu?
Multiple community members regularly test out new package versions on real hardware, in addition to in-house testing by Loongson and their partners.
And with my Gentoo hat on: I regularly test Python packages as they're updated upstream. And as Gentoo heavily depends on Python, any major breakage should be noticeable once it reaches the port's userbase.
Aside from the Loongson teams, there is an active community around LoongArch (also Telegram user group) with multiple porters and power users willing to help. I'm heavily involved in and contributed to many upstream projects' LoongArch support, if it helps.
Yeah, I understand how you try to support the LoongArch for various projects. But maintaining from the CPython is a different story, so what I want to confirm about accepting the patch is that all you have to do is adding a triplet, or do you need more patches in the future that include modifying CPython code with preprocessor?
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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.
rebase update
BTW, for the CPython repo, please don't force push; use git merge --no-ff main instead :) Force-pushing does not play well with the GitHub UI. Also, we squash merge all PRs into a single commit, so it does not matter if the PR commit history is cluttered. See also the devguide.
Aside from the Loongson teams, there is an active community around LoongArch (also Telegram user group) with multiple porters and power users willing to help. I'm heavily involved in and contributed to many upstream projects' LoongArch support, if it helps.
Yeah, I understand how you try to support the LoongArch for various projects. But maintaining from the CPython is a different story, so what I want to confirm about accepting the patch is that all you have to do is adding a triplet, or do you need more patches in the future that include modifying CPython code with preprocessor?
Thanks for clarifying. AFAICT, so far this is the only patch necessary for future binary compatibility between multiarch-aware and -unaware distributions (i.e. Debian & derivatives vs. the others). CPython itself builds and tests fine without this change; only the native extensions have different filename suffixes which is what this patch is trying to reconcile. Hence I don't think more #ifdef-ery should be necessary in the future.
Some more backgrounds though: LoongArch might need more treatment in the future if we'd want to provide perfect UX. There's two incompatible ABIs of LoongArch userland, so native libraries of different ABIs can't be interlinked without invoking UB, but Loongson wants the two ABIs (really two worlds) to share the same multiarch tuple. I expect some friction in the future if some user on one world uploads wheels to PyPI, only to be downloaded by someone on the other world, then failing at import time. It can be said to be a purely downstream problem though; most other upstream projects simply don't consider the "old world" / "ABI v1.0" to exist at all. And even if we do want to care, the changes here still apply: we've already undergone debates and this patch can be seen as the result. (This is kinda orthogonal to the issue at hand; I should probably post this elsewhere for further discussion.)
@erlend-aasland cc @loongson-zn
But on the other hand, if this is the only patch that they will need, I am okay to accept the patch anyway.
@corona10 Currently, this is the only one patch. Because it affects binary compatibility, I believe it is necessary to merge as soon as possible.
@corona10 Currently, this is the only one patch. Because it affects binary compatibility, I believe it is necessary to merge as soon as possible.
Okay, let's pass the CI first, I am +1 with accepting this patch.
Okay, let's pass the CI first, I am +1 with accepting this patch.
@corona10 Thank you for your support. I am debugging errors in CI Docs. I have asked Erlend Aasland about the reason and wating for his reply. If you could tell me the reason, I would be very grateful