GeezerVison is showing github.com — build-details.json is incorrect when using ./configure --with-build-python on a non-cross build · Issue #140266 · python/cpython
build-details.json is incorrect when using ./configure --with-build-python on a non-cross build #140266DescriptionBug report
Bug description:
We noticed that python-build-standalone's build-details.json contains "platform": "" on non-cross builds.
I think I know why. For consistency (I think), python-build-standalone always uses ./configure --with-build-python on both cross builds and normal builds.
This causes configure.ac to do
PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) _PYTHON_SYSCONFIGDATA_PATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`) '$with_build_python
(line 167 in 3.15.0a1), as opposed to PYTHON_FOR_BUILD='./$(BUILDPYTHON) -E' in the without-build-python case.
However, $_PYTHON_HOST_PLATFORM is only actually set to something in the cross-compile case (line 820 in 3.15.0a1), meaning that $PYTHON_FOR_BUILD is effectively doing _PYTHON_HOST_PLATFORM= python3.
The fact that this variable is an empty string, in turn, causes sysconfig.get_platform() to return an empty string:
$ uvx python3.15
Python 3.15.0a1 (main, Oct 14 2025, 21:28:08) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_platform()
'linux-x86_64'
>>> import os
>>> os.environ['_PYTHON_HOST_PLATFORM'] = ''
>>> sysconfig.get_platform()
''
which makes generate-build-details.py output an empty string.
Arguably this is two bugs: configure.ac should not set _PYTHON_HOST_PLATFORM to an empty string, and sysconfig should not misbehave if _PYTHON_HOST_PLATFORM is set to an empty string (and should treat that as equivalent to being unset). Or maybe only one of these is a bug and the other is intended behavior. Also, of course, generate-build-details.py could work around this itself. I'm happy to provide a PR for any or all of these given some feedback on which direction to take this.
This applies to 3.14+ (all versions with build-details.json). If it's helpful, here are our full build logs for 3.14 and 3.15 in GHA; expand the "Build" section and search for generate-build-details. I've patched generate-build-details.py with print(f"generate-build-details debug: {sysconfig=} {sysconfig.get_platform()=}", file=sys.stderr).
(FYI I am probably about to file another bug about build-details.json generation in a moment, which might have a related cause and influence what the fix should be. EDIT: was already reported, #136267, left some analysis there)
CPython versions tested on:
3.14
Operating systems tested on:
Linux
Linked PRs
Reacted by Itamar Oren Reacted by msmojtabafar ActivityKrishna-web-hub commented on Dec 6, 2025 Hi @geofft ,
I have been investigating this issue and already reproduced the problem locally. I also verified that the root cause is _PYTHON_HOST_PLATFORM being set to an empty string when using --with-build-python during a normal (non-cross) build.
I have a working fix where an empty _PYTHON_HOST_PLATFORM is treated the same as unset, and the platform falls back to the correct value (e.g. linux-x86_64).
I want to prepare a PR with tests to confirm the expected behavior.
Let me know if there are any specific preferences for where the check should be applied (configure, sysconfig, or generate-build-details), and I can adjust accordingly.
Thanks! picnixz commented on Dec 6, 2025 If this is a duplicate of #136267, please close this one as such and forward your comment out there. TiA. Krishna-web-hub commented on Dec 6, 2025 Thanks @picnixz for the feedback!
I agree that #136267 describes the broader/root issue with build-details.json mixing data from the build Python and the target Python during cross-builds.
However, I think #140266 exposes a more specific failure mode:
When using --with-build-python on a non-cross build, _PYTHON_HOST_PLATFORM is set to an empty string.
sysconfig.get_platform() interprets the empty variable literally and returns "".
This produces "platform": "" in build-details.json.
My patch treats an empty _PYTHON_HOST_PLATFORM the same as unset, so sysconfig.get_platform() falls back to the correct detected value (e.g. linux-x86_64).
This fixes the incorrect "platform": "" behavior and also aligns with normal expectations.
I’m happy for the PR to reference #136267, and if maintainers prefer to track everything under that issue, I’m okay with closing #140266 as a duplicate.
Just let me know which workflow you prefer picnixz commented on Dec 6, 2025 I actually don't know if this is the correct patch (cc @AA-Turner). added 2 commits that reference this issue on Dec 6, 2025This issue will close once commit 7e29c1c is merged into the 'main' branch.7e29c1c This issue will close once commit b92000e is merged into the 'main' branch.b92000e Krishna-web-hub commented on Dec 7, 2025 picnixz commented on Dec 7, 2025 Please do not rush. I have no idea whether this is the correct fix and so I would prefer that we first hear it from Adam instead. manueljacob commented on Apr 7, 2026 I agree with the analysis. _PYTHON_HOST_PLATFORM is set in configure only if cross-compiling. If not cross-compiling, _PYTHON_HOST_PLATFORM will therefore be substituted in the Makefile with the empty string. However, if --with-build-python is passed, PYTHON_FOR_BUILD will include passing _PYTHON_HOST_PLATFORM no matter whether cross-compiling or not.
_PYTHON_HOST_PLATFORM is used in other places to determine cross-compilation (e.g.
|
default="_PYTHON_HOST_PLATFORM" in os.environ, |
). I think that that is too implicit, as the name of the variable does not tell that it’s about whether cross-compiling or not, but that’s a separate issue. Given the current usage of _PYTHON_HOST_PLATFORM, I think the right fix would be to pass _PYTHON_HOST_PLATFORM based on whether cross-compiling or not instead of whether --with-build-python is passed or not.
I don’t see any reason to ever set environment variable _PYTHON_HOST_PLATFORM to the empty string. Therefore, I do not think that that should be special-cased anywhere (that was done e.g. in the rejected PR).
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|