[3.15] gh-81241: Fix importing ctypes from statically linked interpreters (GH-153890)

[miss-islington]

See astral-sh/python-build-standalone#873.
(cherry picked from commit 5637f4e)

Co-authored-by: Peter Bierma [email protected]

• Issue: import ctypes fails with a statically linked interpreter due to dlopen() failure #81241

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #34933866 | 📁 Comparing 9f4fce3 against main (5637f4e)

  🔍 Preview build  

147 files changed · + 1 added · ± 141 modified · - 5 deleted

+ Added

• library/asyncio-policy.html

± Modified

• glossary.html
• index.html
• license.html
• py-modindex.html
• builtins/exceptions.html
• builtins/functions.html
• builtins/stdtypes.html
• c-api/bytes.html
• c-api/capsule.html
• c-api/complex.html
• and 131 more...

- Deleted

• deprecations/pending-removal-in-3.21.html
• library/tkinter.dialogs.html
• library/tkinter.fontchooser.html
• library/tkinter.systray.html
• whatsnew/3.16.html

[vstinner]

test_pathlib.test_touch_common() failed twice on "Tests / Emscripten / build and test (pull_request)":

FAIL: test_touch_common (test.test_pathlib.test_pathlib.PathSubclassTest.test_touch_common)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/test/test_pathlib/test_pathlib.py", line 2344, in test_touch_common
    self.assertGreaterEqual(st.st_mtime_ns, old_mtime_ns)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1790555994350000000 not greater than or equal to 1790555994351000000

It looks like a flaky test. I just re-run the failed job.

[ngoldbaum]

I had an AI model look at this because @zanieb asked about it on Discord. The model found that statically linked glibc works here, it's only musl that has this behavior. So it's probably more correct to use "may" here instead of "will"

[jjhelmus]

It is a little odd that this fix was included in the 3.13.16 and 3.14.8 releases but was not included in 3.15.0rc3 which was made after these two. Is this fix expected to be included in 3.15.0?

I only ask because in python-build-standalone we include this patch and need to apply it conditionally based on the Python version. Currently is is applied for <=3.12 and 3.15.

[ZeroIntensity]

During the RC phase, changes need approvals from two core devs to make it in. There's only one here (me), so this will have to wait until 3.15.1.

[ngoldbaum]

see https://devguide.python.org/developer-workflow/development-cycle/#rc for the docs on this.

[vstinner]

I don't think that this bug is major enough to justify landing it after Python 3.15.0rc3. It's fine to wait for 3.15.1 bugfix release.