Tier 1 images have no C compiler, so no experiment can build an extension module

[tamnd]

The five pinned CPython images have no C compiler in them. command -v cc gcc clang finds nothing on any of them, and sysconfig.get_config_var("CC") reports gcc, which is not there, so anything that shells out to the compiler dies with FileNotFoundError: 'gcc'.

I ran into this writing C07. The lesson is about the GIL coming back on at run time, and the sharpest demonstration of that is a two line extension module with no Py_mod_gil slot: import it on a free threaded build and sys._is_gil_enabled() flips from False to True, with a warning naming the module. It works on a local free threaded build in about a second. It cannot be a Tier 1 recording, because the image cannot compile the two lines.

The workaround for C07 was to point the recordings at something else and keep the extension build as an ordinary notebook cell that skips itself when there is no compiler. That is fine for one lesson, but it will keep coming up. Anything about the C API tiers, the stable ABI, abi3t, module slots or Py_mod_multiple_interpreters wants to compile something small and watch what the runtime does with it, and R01 through R09 on the M8 list are full of that.

Two possible fixes.

The small one is to install gcc and python3-dev equivalents into the images. They are Debian trixie, so it is one apt-get install line in the Dockerfile. It costs image size and pull time on every recording, which is the thing to weigh.

The larger one is a sixth image, built from the same CPython but with a toolchain on top, and a build="toolchain" value that experiments can ask for when they need one. That keeps the five existing images small and makes the requirement explicit in the experiment definition, which fits how needs already works.

I lean towards the second, but it touches cpybuild, the digest table in tier1.run.image_for and the publish workflow, so it is worth deciding before doing.

Also worth noting while this is open: _testmultiphase is not in the images either, and it is the module CPython's own test suite uses to import a module that declares Py_MOD_GIL_USED without compiling anything. If the images shipped the test extension modules, that would solve the C07 case on its own without a compiler. That may be the cheapest fix of the three.

[tamnd]

Correcting the last paragraph of this issue while looking at what R09 needs. The test extension modules are in the images. All five of _testcapi, _testinternalcapi, _testlimitedcapi, _testmultiphase and the whole test package import fine on the debug, release and free threaded images.

Which means the C07 case can be done without a compiler after all. On the free threaded image, loading the GIL declaring init function out of the _testmultiphase shared object under its own name does exactly what a hand written two line extension would do:

gil at start: False
_test_from_modexport_gil_used loaded, gil now: True

with the runtime warning naming the module, same as ever. The loading is four lines of importlib.machinery.ExtensionFileLoader pointed at _testmultiphase.__file__ with the alternate name. _testmultiphase.c exports a handful of these on purpose, two of them declaring Py_MOD_GIL_USED, which is how CPython's own suite tests this.

One thing to watch if that turns into a recording: the shared object filename carries the architecture, and the local containers are aarch64 under Rosetta while CI is x86_64, so a program must not print the path.

The headers are there too. /opt/python/include/python3.15d on the debug image and /opt/python/include/python3.15 on the release one, both populated. What is missing is only the compiler itself, so sysconfig.get_config_var("CC") still reports a gcc that is not on the path.

So the decision this issue asks for is smaller than it looked. Nothing needs a toolchain image to demonstrate module slots, ABI tiers or the GIL coming back on, because the modules that demonstrate those are already shipped. A toolchain image would only buy the ability to compile a reader's own source in a recording, which is a different and rarer thing. Leaving this open at p2 with that scope, rather than closing it, since R09 does compile an extension and it would be nice to eventually record that too rather than only run it in a notebook.