All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

I'd be happy to sign the CLA, but not happy with providing Python's GitHub app with API access to act on my behalf. I'm attaching a PGP signed message, please consider it as my signed version of CLA:

-----BEGIN PGP MESSAGE-----

owGbwMvMwCX296bGzVSFAjHGtYxsSezJOYl6JRUlmX2nKj11FCITs4szFJwSizIr
E3UUMlKLUpMqFYoz0/MUAipLMvLz1IsVnPPzSooyk0pL8osUfDKTU/OKUxUc04tS
U3NT80oUNJx9HDUVyjITFXIrFQLcAxQKijLLEktSFbJTK/W4uDwVEpOz8/LLc1JT
0lMVSjISSxQ81ctSFYpSE1MUMkpKCoqt9PVBTioAW6eXX5Sur5CYh5ArLy9Hliso
TtNPhjgIRuum5RflQjQlgpylUJKvkJiTA7QMyEwtyi1WADk0Mz8vNUUhM08hs0SP
q6OUhUGMi0FWTJFlioD/5OjgpM2ifNsPwgKKlQkUOgxcnAIwkXgBhv9eP8T33rKZ
/lTlSZ9l1XldZY2TetfcW+YenPl5OXfsUl0HRoYml2dvrusdlVX5oX2jVESKtdy4
M1rRY3dsaueaGJ6v5TwA
=AKa8
-----END PGP MESSAGE-----

@thunder-coding if you do not want to sign the CLA with CLA bot you can fill out the form here: https://www.python.org/psf/contrib/contrib-form/

You could also use the bot and revoke the permissions afterwards. It is open source: https://github.com/psf/clabot

I can confirm that this seems to fix Misc/python.pc... but it also seems to have some other side effects, which don't strike me as obvious improvements:

* `Makefile` hard codes 3.15 everywhere it is used, rather than referencing `$(LDVERSION)`; even the definition of `LDVERSION` was historically build out of `$(VERSION)$(ABIFLAGS)`, and that's no longer the case

* `Misc/python-config.sh` now hard codes library names, rather than using references to internally defined variables.

Even in the context of python.pc - the Libs value evaluates as -L${libdir} -L. -lpython3.15. The inclusion of -L. seems like an error to me.

So - while this fixes the problem described, I'm not completely convinced it's the right fix.

Yep, that -L. is actually an error. And I can confirm that is an error that should not happen. I've mentioned about this in the commit message. Please check it out. And this should be fixing things properly without causing any breakages or hardcoding LDVERSION/ABIFLAGS

Honestly, I'm tired with this autotools since the beginning of this PR. The first version of the PR along with the 6+ versions I have had pushed (excluding the ones I did not push because I revised them locally), all I have dealt with autotools in a really annoying manner. Any minor change I do in the build process breaks builds for some other target which shouldn't even have a minor impact of the change at all. For every change I have to ./configure, wait for it to finish, and analyze the generated Makefiles to figure out where things went wrong. Ideally I should be able to look at the build configuration, and figure out without having to run anything but this isn't possible as there are some variables which are being used before they are being declared, thanks to the weird substitution technique in autotools of '$(VARIABLE)'

I can offer to rewrite the build system in something more modern, more easy to work with for both Python contributors as well as others in the Python ecosystem who want to develop extensions for Python. Many projects have moved over from autotools to more modern build systems like CMake, Meson. I think it's time for CPython as well to make the change now.

Git is transitioning from autotools to meson: git/git@904339e
LLVM has migrated from autotools to CMake since a while now

I can probably look forward to fixing this issue without moving to a more modern build system, but I do strongly believe that Python needs to make the switch in order to support multiple platforms in the long run, as it'll ensure ease to work with build scripts without someone having to loose their mind and 8 hours trying to figure out how each variable is being assigned.

For discussion on modernising the build system:

• https://discuss.python.org/t/what-do-you-want-to-see-in-tomorrow-s-cpython-build-system/28197
• https://discuss.python.org/t/what-do-you-consider-pain-points-of-todays-build-system/31815
• https://discuss.python.org/t/what-should-be-used-to-build-the-cpython-of-tomorrow/36001

I suggest following up there (the first is unlocked).

There's clearly some other side effects to this change; holding off on a review until CI is passing.

@thunder-coding: Sorry, I don't know why the CLA process is taking so long. Meanwhile, please post a comment saying "I license this PR to the Python Software Foundation under the Apache License, Version 2.0". That will at least allow me to look at the code and copy it to a PR of my own if necessary.

Sorry, I couldn't get the time to properly test this PR for builds. Marking this as draft once again. The build system is just painful to deal with, so will be trying to give this another shot with a fresh mind this weekend

And for CLA:

I license this PR to the Python Software Foundation under the Apache License, Version 2.0

@thunder-coding please click on the link here to sign the CLA:
#144776 (comment)

The PDF form you signed is for organizations.

BTW: the "Act on your behalf" permission is poor wording on GitHub's part, which is pretty widely discussed online. The actual "acting on your behalf" is restricted to the other permissions that are listed on the same screen. In the case of our app it is literally just the ability for the app to see which email addresses belong to you and what repositories under the python/ organization you have access to. There's no write access for anything.

@mhsmith please don't suggest people "sign CLAs" by posting comments. This is not a process that was vetted by legal.

Based on the PDF form we received, I manually approved the email address linked to the GitHub username as having signed the CLA. Please proceed with the review, @mhsmith.

Thanks very much Łukasz. The tests are currently failing, so hopefully @thunder-coding will be able to deal with that soon, and then I'll do the review.

Even in the context of python.pc - the Libs value evaluates as -L${libdir} -L. -lpython3.15. The inclusion of -L. seems like an error to me.

The only places that should have -L. are the command lines for building the extension modules in the stdlib, which are generated by makesetup. So I've added the argument there.

• Makefile hard codes 3.15 everywhere it is used, rather than referencing $(LDVERSION); even the definition of LDVERSION was historically build out of $(VERSION)$(ABIFLAGS), and that's no longer the case
• Misc/python-config.sh now hard codes library names, rather than using references to internally defined variables.

I can't see the commit you were responding to here, but the current approach only affects the LIBPYTHON variable, which will now become a string like -lpython3.16 without any variable references. Since it has to be used in the .pc file where the variables aren't available, I think that's acceptable.

The .pc line now looks like this on Android:

Libs: -L${libdir} -lpython3.16

That's a reasonable point, I'll see if I can remove it.

I've updated makesetup to use a new Makefile variable, MODULE_LDFLAGS_SHARED, which has the same value as BLDLIBRARY when extension modules should be linked against libpython, and is otherwise empty.

Thanks @thunder-coding for the PR, and @freakboy3742 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15.
🐍🍒⛏🤖

GH-155107 is a backport of this pull request to the 3.15 branch.

Sorry, @thunder-coding and @freakboy3742, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 5918085bb6f4a3a48193cacb9bb99b044d4e0452 3.13

GH-155108 is a backport of this pull request to the 3.14 branch.

GH-155111 is a backport of this pull request to the 3.13 branch.