Builds outside source folder broken, failed import of _importlib - no detection or valid error message or recommended cleanup.

[nascheme]

Bug description:

This bug was exposed by GH-108716. I think it was not the cause, just that it exposed an existing issue.

The build fails with:

./python -E -c 'import sys ; from sysconfig import get_platform ; print("%s-%d.%d" % (get_platform(), *sys.version_info[:2]))' >platform
Fatal Python error: _PyImport_InitCore: failed to initialize importlib
Python runtime state: preinitialized
ImportError: Frozen object named '_frozen_importlib' is invalid

Current thread 0x00007fb629644740 (most recent call first):
  <no Python frame>
make: *** [Makefile:932: platform] Error 1

Likely python doesn't know to look in $(srcdir)/Lib for the _importlib library. It probably looks in ./Lib/ and that fails.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-112305: Fix check-clean-src to detect frozen_modules .h files. #113344
• [3.12] gh-112305: Fix check-clean-src to detect frozen_modules .h files. (GH-113344) #113346
• [3.11] gh-112305: Fix check-clean-src to detect frozen_modules .h files. (GH-113344) #113347

[gpshead]

I build out of tree all the time on Linux without trouble. But this hits me every time on macOS these days.

I am often (not always) unable to build on a Mac in the best way to do all development: out of source tree builds.

b$ ./python.exe -E -S
Fatal Python error: _PyImport_InitCore: failed to initialize importlib
Python runtime state: preinitialized
Exception ignored in the internal traceback machinery:
SystemError: null argument to internal routine
ImportError: Frozen object named '_frozen_importlib' is invalid

the build step hitting that is the generate sysconfig data one.

[gpshead]

I managed to "fix" it on one system by doing an in-tree build, followed by a make distclean. now my out of tree builds work.

this smells like something not-quite up to date and synchronized related to _frozen_importlib when taken from a git checkout maybe?

[erlend-aasland]

Out-of-tree builds require a clean source tree; I recommend doing a git clean -fdx before starting the out-of-tree build.

[nascheme]

I tested with a clean checkout and a build in a sub-folder and it works. Closing.

[gpshead]

We do still have a problem here: My git repos often wind up in this state and I never do in-tree builds and nothing in our build process detects whatever the underlying issue is and provides any form of cleanup. So winding up in Fatal Python error: _PyImport_InitCore: failed to initialize importlib will continue to happen to people.

I don't want our answer to this to be "give up, delete your repo, and start over".

git clean -fdx did not solve my problem.

[gpshead]

I'm leaving this open because so long as i've got a tree on one machine that leads to this, i've at least got a datapoint where I can investigate further what is going on.

my workflow involves frequently switching branches in that git repo, including old stable release branches to modern branches. I don't believe we always do the right thing in this back and forth situation. some dirtiness within the source tree from our runtime or build process that is ignored by git seems to accumulate.

[gpshead]

The check-cleanup-src target had a typo in its checks. It was failing to detect Python/frozen_modules/*.h files in the source directory tree. PR added.

[gpshead]

backports set to auto-merge. I didn't try to figure out why I had clients in this state given I don't do in-tree builds as a habit... but it doesn't matter. transient leftover bits over time in my clients that mostly hide by default due to .gitignore? now gone. and identified in the future. :)