This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients christian.heimes, eric.snow, gvanrossum
Date 2021-11-23.23:00:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1637708408.41.0.945674437753.issue45886@roundup.psfhosted.org>
In-reply-to
Content
To the question "why does _freeze_module need to be a (C) binary" (IOW, why can't it be replaced by a Python script that is run with PYTHON_FOR_REGEN, which always runs on the build host), the reason is that it uses the bytecode compiler to generate correct output. The bytecode compiler is written in C and depends on many other parts of the runtime. Bytecode is not compatible between versions (and in 3.11 it is an especially moving target) so we absolutely must use the bytecode compiler from the current source tree.

Fortunately bytecode *is* portable across OS and CPU versions, so there is no problem with taking a _freeze_module binary compiled for the build host and running it there (on the build host). It *is* complicated to build a binary for the build host in a tree configured for cross compilation though -- you'd have to do an out-of-tree build configured for the build host platform. Rather than solving *that* problem, Christian proposes to let the user solve that, and allowing the user to pass in the path to the host platform _freeze_module binary.
History
Date User Action Args
2021-11-23 23:00:08gvanrossumsetrecipients: + gvanrossum, christian.heimes, eric.snow
2021-11-23 23:00:08gvanrossumsetmessageid: <1637708408.41.0.945674437753.issue45886@roundup.psfhosted.org>
2021-11-23 23:00:08gvanrossumlinkissue45886 messages
2021-11-23 23:00:08gvanrossumcreate