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 EdSchouten
Recipients EdSchouten, martin.panter
Date 2016-09-11.06:25:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473575105.93.0.0980783974452.issue28066@psf.upfronthosting.co.za>
In-reply-to
Content
The nice thing is that in our case, the importlib changes are already compatible with the native build. So yes, we can reuse the frozen module from the native build. :-)

Ah, yes. Issue 27641 already prevents that it's cross compiled. This patch was written prior to that and simply rebased.

Still, one problem remains: our strategy for creating importlib.h and importlib_external.h doesn't take out-of-tree builds into account. Even if we regenerate it, frozen.c won't pick it up because its directory is not part of the compiler search path.

Attached is a patch that makes us write the results of _freeze_importlib into $(srcdir)/Python/importlib*.h instead, so that even with an out-of-tree build, we actually update the header files used by frozen.c.
History
Date User Action Args
2016-09-11 06:25:05EdSchoutensetrecipients: + EdSchouten, martin.panter
2016-09-11 06:25:05EdSchoutensetmessageid: <1473575105.93.0.0980783974452.issue28066@psf.upfronthosting.co.za>
2016-09-11 06:25:05EdSchoutenlinkissue28066 messages
2016-09-11 06:25:05EdSchoutencreate