GeezerVison is showing github.com — Deepfreeze using 3.10, not bootstrap interpreter. · Issue #93771 · python/cpython
Deepfreeze using 3.10, not bootstrap interpreter. #93771Description#93769 shows this error, for the Windows build.
py -3.10 "D:\a\cpython\cpython\Tools\scripts\deepfreeze.py
Yet, the deepfreeze script states that "The script is executed by _bootstrap_python interpreter."
I need deepfreeze to be able to scan the bytecode looking for a RESUME instruction, to avoid computing it at runtime. Activitygvanrossum commented on Jun 13, 2022 We may need help from @zooba to fix the build files. (Do we even have a bootstrap interpreter on Windows?) zooba commented on Jun 13, 2022 We have _freeze_module, which is just enough interpreter to do what Programs/_freeze_module.c implements (which can obviously be extended if necessary), but because we can't reuse object files it's a serious slowdown to rebuild the entire interpreter.
If there's really no way to do it without a full interpreter, we'll want to split most of the runtime into a static library. That should let us compile almost everything, then build an exe to do what you need, then build the real one, and reuse most of the object files via the static lib. (I say "we" because, even though it'll probably be me, I don't want to block someone else from doing it.)
Can you maybe parse the opcode value out of one of the other files for this? Or teach _freeze_module how to print out the value for you? gvanrossum commented on Jun 13, 2022 Mark solved it by hardcoding RESUME. markshannon commented on Jun 14, 2022 Would it make sense to just fix the comment? Something like "This script should be executable by any reasonably recent Python". zooba commented on Jun 14, 2022 I think it's minimum 3.10 now because of a match statement, so we can be more concrete than "reasonably recent". kumaraditya303 commented on Jun 15, 2022 Guido replaced the match statement with an if-else chain so that deepfreeze can run with older versions of Python in #29717 gvanrossum commented on Jun 15, 2022 The rules appear to be even more complicated.
- By default on UNIX it uses
_bootstrap_python
- For cross-builds on UNIX it uses an external Python (determined by the configure script)
- On Windows it uses an older Python version (one must exist)
zooba commented on Jun 15, 2022 Do cross-builds on UNIX require the external Python to be built from the exact same commit? If not, it's probably the same as the Windows rule (which just requires an external version, not necessarily an older version). gvanrossum commented on Jun 15, 2022 I dunno without investigating the code in much detail. The reasoning around using bootstrap python has gone back and forth too many times. :-( gvanrossum commented on Jun 23, 2022 @kumaraditya303 Do you recall why it has to be run with _bootstrap_python at all on UNIX? kumaraditya303 commented on Jun 23, 2022 _bootstrap_python is used mainly because of cross compilation and was (re)introduced in #29859. You can read #90108 issue for rationale.
gvanrossum commented on Jun 23, 2022 Fixed by #94150 and #94179 (3.11 backport).
The reason to use _bootstrap_python is that otherwise users would have to install Python 3.10 in order to build 3.11. (See #90108 (comment) where this is said.)
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|