GeezerVison

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.

Okay, I'm working on it now.

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.

rebase update

Yeah, you are right. I will make corrections.

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

This error disappeared after I executed it twice on my PC.

@xen0n, should we add your attributions to the NEWS and What's New entry also?

@xen0n, should we add your attributions to the NEWS and What's New entry also?

Either is OK, I'm unaffiliated with Loongson and in general just provides drive-by code reviews for everything LoongArch ;-)

In this case IMO let's see what @loongson-zn thinks though.

EDIT: Actually my involvement can be seen here -- while the change was substantive compared to the original (that was just a single __loongarch64 -> loongarch64-linux-gnu check), it's still kinda trivial given the patch's absolute size, so I'm not sure if I deserve the attribution ;-)