GH-138800: fix variable substitution in python3.pc for Android

[thunder-coding]

7f5e3f0 introduced the change to LIBPYTHON where it erraneously depended on BLDLIBRARY which contained -L. -lpython$LDVERSION, this PR addresses that and attempts to fix it

Patch stolen from downstream distribution of Python for Termux (Android): termux/termux-packages#27739 The patch was broken as pointed out by @freakboy3742 , and now will be replaced with this PR's patch.

Preferably needs to be backported to both Python 3.13 as well as Python 3.14, along with the main branch

Fixes #138800

• Issue: .pc for Android contains invalid syntax #138800

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

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.

[thunder-coding]

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-----

[emmatyping]

@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

[thunder-coding]

Oops, looks like I did a rebase which has managed to pinged a lot of people. Apologies for the mess I created. I can start up with another PR in order to reduce the spam I unintentionally created.

And I've signed the CLA on https://www.python.org/psf/contrib/contrib-form/, but doesn't seem to have been updated here yet

[mhsmith]

The Android builds are still failing on GitHub Actions because of a failure to link against libpython. Please fix this, and post a comment asking for a review once the tests are passing.

Now that other people have seen the PR, please make further changes using regular and merge commits, not rebases.

[thunder-coding]

This should be ready for review now. Took a while to figure out in the autotools wildness, but was just a result of me not knowing autotools well enough.

I've signed the CLA via https://www.python.org/psf/contrib/contrib-form/, doesn't seem to be updated here.

[thunder-coding]

This should be finally ready for review. Noticed that the substitution wasn't happening correctly after marking as ready for review earlier. Had to touch up way more than I thought I needed to.

Autotools is a real mess to deal with!

[mhsmith]

I've signed the CLA via https://www.python.org/psf/contrib/contrib-form/, doesn't seem to be updated here.

Did you get the "automated verification email that you will need to respond to before your Agreement can be processed"?

[thunder-coding]

Did you get the "automated verification email that you will need to respond to before your Agreement can be processed"?

Yes I did, and also did receive a mail saying "You're done signing
Contributor License Agreement V12_2021"

[freakboy3742]

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.

[mhsmith]

Did you get the "automated verification email that you will need to respond to before your Agreement can be processed"?

Yes I did, and also did receive a mail saying "You're done signing Contributor License Agreement V12_2021"

@JacobCoffee it looks like this was signed more than a week ago; how should we proceed?

[thunder-coding]

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

[thunder-coding]

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.

[hugovk]

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).

[freakboy3742]

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

[mhsmith]

@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.

[thunder-coding]

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

[ambv]

@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.

[ambv]

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

[ambv]

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.

[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.