Skip to content

Conversation

@zanieb
Copy link
Contributor

@zanieb zanieb commented Nov 25, 2025

An alternative to #141927 just removing what appears to be legacy code instead of providing a way to opt-in to different behavior.

Closes #141926
Closes astral-sh/python-build-standalone#864

Copy link
Member

@FFY00 FFY00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think RUNSHARED should only need to be cleared to run the built interpreter on edge cases. Since nowadays it's more likely we need to keep it, I think it makes sense to keep it by default, and add some logic to adjust it when needed.

@FFY00 FFY00 added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 4, 2025
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @FFY00 for commit 9152608 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F141958%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Dec 4, 2025
@emmatyping
Copy link
Member

I think RUNSHARED should only need to be cleared to run the built interpreter on edge cases.

Wouldn't cross-compiling from say x86_64 to aarch64 on Linux where you haven't configured binfmt-misc to handle ARM binaries break? I know that is not uncommon to build software for SBCs like a Raspberry Pi with this setup.

@zanieb
Copy link
Contributor Author

zanieb commented Dec 4, 2025

Wouldn't cross-compiling from say x86_64 to aarch64 on Linux where you haven't configured binfmt-misc to handle ARM binaries break?

Break at what step though? It looks like, e.g., PGO still runs when cross-compiling, so clearing RUNSHARED won't save you and this shouldn't cause a regression.

@emmatyping
Copy link
Member

Break at what step though? It looks like, e.g., PGO still runs when cross-compiling, so clearing RUNSHARED won't save you and this shouldn't cause a regression.

Yeah thinking this over a bit more, I think you're right that any use-case where this could regress is either completely or subtly broken anyway.

@zanieb
Copy link
Contributor Author

zanieb commented Dec 4, 2025

I presume these test failures on the refleaks bots are flakes? e.g.:

======================================================================
ERROR: test_interrupt (test.test_multiprocessing_fork.test_processes.WithProcessesTestProcess.test_interrupt)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/contextlib.py", line 85, in inner
    return func(*args, **kwds)
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/test/_test_multiprocessing.py", line 597, in test_interrupt
    exitcode = self._kill_process(multiprocessing.Process.interrupt)
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/contextlib.py", line 85, in inner
    return func(*args, **kwds)
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/test/_test_multiprocessing.py", line 578, in _kill_process
    self.assertEqual(join(), None)
                     ~~~~^^
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/test/_test_multiprocessing.py", line 251, in __call__
    return self.func(*args, **kwds)
           ~~~~~~~~~^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/multiprocessing/process.py", line 156, in join
    res = self._popen.wait(timeout)
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/multiprocessing/popen_fork.py", line 44, in wait
    return self.poll(os.WNOHANG if timeout == 0.0 else 0)
           ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/multiprocessing/popen_fork.py", line 28, in poll
    pid, sts = os.waitpid(self.pid, flag)
               ~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/test/_test_multiprocessing.py", line 574, in handler
    raise RuntimeError('join took too long: %s' % p)
RuntimeError: join took too long: <Process name='Process-1708' pid=2226706 parent=2212089 started daemon>

----------------------------------------------------------------------
Ran 162 tests in 33.825s

FAILED (errors=1, skipped=7)
test test.test_multiprocessing_fork.test_processes failed

@FFY00
Copy link
Member

FFY00 commented Dec 5, 2025

Yeah, the buildbot failures are unrelated, we are okay.

@FFY00 FFY00 merged commit 128d316 into python:main Dec 5, 2025
103 of 105 checks passed
StanFromIreland pushed a commit to StanFromIreland/cpython that referenced this pull request Dec 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support PGO in cross-compiles when transparent emulation is available Upstream patch patch-dont-clear-runshared-14.patch

4 participants