When TSAN build fails for env reasons, it corrupts the build dir

[crusaderky]

Bug report

Bug description:

A failure to build TSAN caused by incorrect runtime configuration in the OS leaves me with a broken build directory, unrecoverable after I fix the OS setting.
I'm reproducing this issue with #142872, but I have no reason to believe it is pixi-specific.

Reproducer

1. In Linux, call

sudo sysctl vm.mmap_rnd_bits=32

which should be the default for Ubuntu 24.04 (but notably not for ubuntu-24.04 github workers).

2. With pixi >=0.63.2, have pixi.toml:

[workspace]
channels = ["https://prefix.dev/conda-forge"]
platforms = ["linux-64"]
preview = ["pixi-build"]

[dependencies]
python.git = "https://github.com/crusaderky/cpython"
python.rev = "tsan"
python.subdirectory = "Tools/pixi-packages/tsan-freethreading"

(which points to #142872) and run pixi s.
It should crash on a test command with bus error as soon as it test-runs the python interpreter it just built, because TSAN does not support vm.mmap_rnd_bits higher than 28.

3. Run

sudo sysctl vm.mmap_rnd_bits=28

4. Run again pixi s. It will resume using the previous build dir in .pixi/build with make install (./configure earlier completed successfully, so it is skipped) and crash again, until you run pixi clean or rm -r .pixi/build, citing missing files in the install directory.

Expected behaviour

make install resumes from the latest failed step, without skipping any.
To my underestanding, vm.mmap_rnd_bits should not impact on the compiled binaries, as it should be read at runtime by them for the first time when you execute them.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

[crusaderky]

CC @isuruf @lucascolley @kumaraditya303 @ngoldbaum

[crusaderky]

I had an offline with @kumaraditya303, who informed me that vm.mmap_rnd_bits changes the compiled output. So the failure at runtime is because the compiled python executable is corrupted and irrecoverable, and changing vm.mmap_rnd_bits after that won't fix it.

This behaviour, incidentally, also makes it extremely hard to publish pre-built TSAN libraries on any packaging system other than Docker.

Closing this issue as this is core TSAN behaviour and unrelated with the cpython build scripts.