Repository navigation
Conversation
…-compiling In a cross build the build Python is the --with-build-python interpreter. Running it with RUNSHARED puts the target's build directory on the library path, so a shared build Python of the same version loads the target's libpython, which fails when the target uses another libc. Add RUNSHARED_FOR_BUILD, empty when cross-compiling, and use it for $(PYTHON_FOR_BUILD). RUNSHARED itself is unchanged, so the PGO profile run (pythongh-141926) and TESTPYTHON still get it.
aozmekik
requested review from
AA-Turner,
corona10,
emmatyping,
erlend-aasland and
itamaro
as code owners
November 4, 2026 15:40
|
All commit authors signed the Contributor License Agreement. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When cross-compiling, the build Python is the
--with-build-pythoninterpreter, but the Makefile still ran it withRUNSHARED. With--enable-sharedthat puts the target's build directory onLD_LIBRARY_PATH, so a shared build Python of the same version loads the target'slibpython3.X.so.1.0instead of its own. glibc to glibc gets away with it; for a musl target the loader then fails on musl'slibc.so.This adds
RUNSHARED_FOR_BUILD, which is$(RUNSHARED)in native builds and empty in cross builds, and uses it where the Makefile runs$(PYTHON_FOR_BUILD).RUNSHAREDitself doesn't change, so the PGO profile run from gh-141926 still gets it.TESTPYTHONkeeps it too, since withHOSTRUNNERregrtest starts the target interpreter from it.Tested on Ubuntu 24.04 with a shared build Python from the same commit:
musl-gcc,--enable-shared): main fails atpybuilddir.txtwitherror while loading shared libraries: /lib/x86_64-linux-gnu/libc.so: invalid ELF header. With this change the build,make install(ensurepip) and the cross-built interpreter all work.--enable-optimizations: passes before and after, and the profile run still getsLD_LIBRARY_PATH. ClearingRUNSHAREDfor cross builds again, as before 3.15, breaks it (libpython3.16.so.1.0: cannot open shared object file).