Repository navigation
build-details.json is incorrect when using ./configure --with-build-python on a non-cross build #140266
Description
Bug 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
Activity
Krishna-web-hub commentedon 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 commentedon 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 commentedon 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 commentedon Dec 6, 2025
I actually don't know if this is the correct patch (cc @AA-Turner).
Fix build-details platform handling and adjust traceback test(fixes p…
Fix build-details platform handling and adjust traceback test(fixes p…
Krishna-web-hub commentedon Dec 7, 2025
Thanks! I’ve opened the PR at #142375. Looking forward to feedback from @AA-Turner.
picnixz commentedon 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.
pythongh-140266: Fix data race when accessing func_code in PyFunction…
manueljacob commentedon Apr 7, 2026
I agree with the analysis.
_PYTHON_HOST_PLATFORMis set inconfigureonly if cross-compiling. If not cross-compiling,_PYTHON_HOST_PLATFORMwill therefore be substituted in theMakefilewith the empty string. However, if--with-build-pythonis passed,PYTHON_FOR_BUILDwill include passing_PYTHON_HOST_PLATFORMno matter whether cross-compiling or not._PYTHON_HOST_PLATFORMis used in other places to determine cross-compilation (e.g.cpython/Tools/build/check_extension_modules.py
Line 112 in 8a73478
_PYTHON_HOST_PLATFORM, I think the right fix would be to pass_PYTHON_HOST_PLATFORMbased on whether cross-compiling or not instead of whether--with-build-pythonis passed or not.I don’t see any reason to ever set environment variable
_PYTHON_HOST_PLATFORMto the empty string. Therefore, I do not think that that should be special-cased anywhere (that was done e.g. in the rejected PR).